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1981 

Hoare, C.A.R., The Emperor’s Old Clothes. 1980 ACM Tur- 
ing Award Lecture, Comm. ACM, 24, 2, February 1981. 77. 

This is the latest reference to an anecdote that points to a design 
Haw in the FORTRAN language that is much more apparent in 1981 
than would have been considered in 1954. Hoare criticizes the lack 
of strong typing in fortran and cites “The story of the Mariner 
space rocket to Venus, lost because of the lack of compulsory 
declarations." Further research revealed two earlier references to 
this story. -J. Horning (“A Note on Program Reliability," ACM 
SUNSOFT. Software Engineering Notes 4. 4, October 1979, 6) says: 
"The first American Venus probe was lost due to a program fault 
caused [3] by the inadvertent substitution of a statement of the 
form 

DO 31 = 1.3 

for one of the form 

DO 3 I = 1,3" 

Horning s re I ere nee 3 is: G.J. Meyers, Software Reliability: Princi- 
ples and Practices, John VVilev & Sons. New York. 1976, p. 275. 

Backus. J.W., The FORTRAN Session. In R.L. Wexelblat 
(ed.). History of Programming Languages, Academic Press, 
New York. 1981. pp. 25-74. 

1981-1982 

'Papes and transcripts of the following three interviews have 
been archived with the Charles Babbage Institute, Univer- 
sity of Minnesota. Minneapolis, Minn. Copies are also in 
the Fortran Archive of the Special Collections Division, 
Carol E. Newman Library, Virginia Tech. Blacksburg, Va. 

Lee, J.A.N. ted.), Oral Interview with Florence Pessin, 1981. 

This interview focuses on Flo Pessin’s involvement with FOR- 
TRAN developments at IBM beginning in February 1957. She was 
assigned to Boh Berner’s group and worked with Otto Alexander 
and Dave Hemmes initially on what became fortransit for the 
bat). Next came 7070 fortran and then Commercial Translator, 
where she was one of the designers. The main emphasis of this 
discussion is on some of the technical aspects of the language 
developments. Lee has annotated the transcript with comments by 
Otto Alexander. Alexander’s comments fill in some gaps and in a 
few cases elaborate on a particular technical aspect. —Henry S. 
Tropp 

Lee. J.A.N. (eci.). Oral Interview with Robert Berner, 1982. 

The central topics of this discussion are the development of 
FORTRANSIT and xtran at IBM under Berner’s direction. In the 
process, some of the early controversy surrounding early support 
for Al.tiOL in and out of IBM and SHARE surfaces just enough to 
whet the reader’s curiosity. Berner has controversial views in a 
number of areas involving the philosophy of language design. Some 
brief annotations by Flo Pessin are included: one focuses on a basic 
disagreement between her and Berner about the 650 project that 
continues today. The transcript ends abruptly because of a tape 
malfunction. — H. S. Tropp 



Lee, J.A.N. (ed.), Oral Interview with Harry Cantrell, 1982. ' 
Cantrell talks about his early days as an engineer and the 
computational aids he had available for numerical calculation*. T 
including the IBM 604, the IBM 402 and sorter, the CPC, and even 
a 701. He discusses the role SHARE played in his early involvement 
with fortran and the attitudes he had at that time about program-:- 
ming in general. At one point when asked, “If. . . fortran had 
been delivered and it didn’t do a good job of optimizing code, would 
you have stayed with it?” Cantrell answered, “I’m sure we* would 
have.’’ Cantrell closes the discussion with the way he views futm»3§7 
language developments given his evolutionary view since the intio-^ 
duction of FORTRAN. —H. S. Tropp 


The following papers were included in the NCC Proceedings, ~ 
AFIPS Press, 1982, and are reviewed elsewhere in this issue. T 
Allen, F.E., A Technological Review of the FORTRAN I /• 
Compiler, pp. 805-809. 

Berner, R.W.. Computing Prior to FORTRAN, pp. 812-816. v 

Greenfield. M.N., History of FORTRAN Standardization" !- 
pp. 817-824. 

Sakoda. J.M., DYSTAL: Non-numeric Applications of FOR- - • 
TRAN. pp. 825-830. 

Also worthy of note is the newsletter of FORTRAN enthusi; J 
asts. published on an irregular basis: L.P. Meissner (ed.),-. 
For- Word Fortran Development Newsletter, Lawrence .: 
Berkeley Laboratory, Berkeley, 1975-1982. The publication V 
of this newsletter was terminated on the establishment of 
the ACM/SIGPLAN technical committee on FORTRAN J 
(FORTec) in 1982, and the initiation of the FORTec Forum L 
Newsletter. 


American Standards Documents 


American Standard FORTRAN. American Standards As* jf 
sociation X3.9-1966. Approved March 7, 1966. 

American Standard Basic FORTRAN. American Standards ... Y 
Association X3. 10-1966. Approved March 7, 1966. 


American National Standard Programming Language FOR-wi 
TRAN. ANSI X3.9-1978. Approved April 3, 1978. 

The revision of ANSI X3.9-1966; X3. 10- 1966 on basic FOR' 
was withdrawn. 


?'■ 
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FORTRAN Anecdotes 

HENRY s. tropp, editor 


One of the fascinating by-products of any Pioneer Day 
celebration is the gathering of the team of people who 
brought the epochal event into being. Many of them 
haven’t seen each other for 20 years or more, and the 
event being celebrated took place perhaps a quarter of 
a century earlier. The gathering takes on all the won- 
derful aspects of a class reunion. Twenty-five years 
earlier they had lived in each other’s pockets trying to 
get a job done that no one had ever done before. They 
had worked around the clock on many occasions, left 
family for days or weeks, moved into a laboratory for 
long weekends. Then when the project became a real- 
ity, they moved into new arenas of activity and 
climbed new heights. 

Now they begin to drift into NCC and slowly renew 
each other’s acquaintance. By the night before Pioneer 
Day, the stories begin to flow. The Pioneer Day ses- 
sions are serious attempts to reconstruct the historical 
record, but by evening, when the pioneers meet for 
dinner, the memories flow fast and furious. Most of 
the best stories are told in small gatherings. Every 
reader has been there and knows the exhilaration of 
the '‘Hey, remember when. . . .” 

Anecdotes are an integral part of the historical 
record. They tell us much that cannot be conveyed in 
the formal documentation. Through these stories, we 
come as close as we ever will to re-creating the excite- 
ment of the project and to learning some vital things 
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about the most important component of any historical 
event: the people who made it happen. The FORTRAN 
gathering was no exception. To the world, FORTRAN 
is a programming language. To the people who made 
it happen, it was an event. 

A good many of the stories about the early days of 
fortran are probably lost forever. Many surfaced 
during the Pioneer Day celebration, and some are 
recorded here. J. A. N. Lee, being tenacious, wrote to 
a number of individuals to try to get them to put their 
recollections down on paper. In some cases, he tried 
to verify a particular anecdote by circulating it and 
getting reactions from other participants. A good il- 
lustration is an anecdote that Ken Butler told him at 
IBM’s Santa Teresa Laboratory while JAN was vis- 
iting there during 1980-1981. This is followed by Ken 
Powell’s elaboration, a partial verification by Frank 
Engel, and the story JAN told at the Pioneer Day 
banquet. 

Original Tale 

When FORTRAN was first released, Westinghouse was con- 
cerned about the efficiency of the compiler and so requested 
a copy of the source code from IBM. Even then (1957) the 
initial response was “we don’t provide source code,” but after 
some haggling it was obtained for them. Westinghouse then 
proceeded to improve the code and improved the through- 
put of the compiler considerably. IBM was so impressed 
that they asked Westinghouse for the source code, to which 
Westinghouse replied: “We don’t supply source code.” 

Ken Butler 

IBM Santa Teresa Laboratory 
Second Version 

By the middle 1950s, SHARE, under the leadership of 
Ramshaw, Engel, and others, had begun to insist that the 
vendor should supply software. This idea was not welcomed 
enthusiastically by IBM since nearly all software (assem- 
blers, interpreters, a few utilities, and some primitive IOCS 
programs) were ad hoc operations. For SHARE customers, 
the efforts were truly shared by all, with IBM being a 
minority contributor — primarily out of Applied Science. By 
the late 1950s, IBM had agreed to supply FORTRAN. Frank 
Beckman of IBM and Frank Engel of Westinghouse had 
agreed to a preliminary trial at Westinghouse (East Pitts- 
burgh). As the combination sales and Applied Science rep, I 
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delivered an early tape and a few pages of documentation. 
At this time, the importance (and difficulty) of supplying 
documentation was just beginning to be understood by the 
programming community. Frank Engel was, however, far 
ahead of the field. Furthermore. I’ve seen him read extensive 
octal dumps like a novel — dumps which I’m certain he’s 
never seen before and which he immediately and successfully 
fixed. Engel’s first reaction on receiving the preliminary 
fortran tape was to demand more documentation. Since 
the documentation was done last, it of course did not exist. 
Engel’s next reaction was to try some typical application 
and to observe the behavior of the tapes. Then he scanned 
an octal dump and fixed the FORTRAN compiler to run 
significantly faster. Finally, within 24 hours, he mailed the 
faster tape to Heckman — who requested the documentation! 
All very logical— if one understands the state of the art at 
the time. 

Ken Powell 

IBM, Poughkeepsie N. Y. 

Partial Verification 

I wish I could confirm the details, but alas, I don’t seem to 
have in my files any notes relating to that early FORTRAN 
experience. I do recall that we had a very minimal hardware 
configuration at Westinghouse, Pittsburgh, and for that 
reason may have been using the FORTRAN compiler in a 
configuration that had not received as much attention from 
t he developers of the system. At any rate. I do recall standing 
in the computer room watching the flashing lights and 
observing tape activity, from which it was easy to infer that 
there was appreciable time lost positioning the tapes, waiting 
for rewinds and counting down records. Our contribution 
was to improve performance through redistribution of pro- 
gram and data segments among the available tape units, 
prepositioning reels by anticipating rewinds, etc. Whether 
this all happened as quickly as Ken Powell alleges. I can’t 
sav. 

Frank Engel 

Belmont, Mass. 

The attempt to reconstruct the incident of the un- 
available source code does not end here. JAN contin- 
ued to probe. Finally, at the FORTRAN banquet, he told 
the story. 

Final Version 

Everybody knew that fortran could be improved. And 
when Westinghouse, Pittsburgh, got its compiler, Frank 
Engel, whom you may remember invented several other 
versions of fortran, noticed that none of the tapes ever 
moved at the same time as another tape moved. So he 
decided he could improve the through-put, if only he could 
overlap the tape operations. His system engineer at that 
time was Ken Powell, and Ken Powell reported to Frank 
Beckman. And so Frank Engel asked Ken, “Can I have a 
copy of the source code, please?” Ken called up Frank 
Beckman and said, “I’ve got this customer out here who 
wants the source code.” Beckman replied, “IBM does not 
supply source code.” This was relayed back to Engel, who 
decided that he would dump the compiler in octal; he patched 
it in octal, having decompiled it in his mind, and improved 
the through-put by a factor of 3. Now Powell, on one of his 
regular visits, noticed that the FORTRAN compiler was work- 
ing very quickly. He said to Engel, “What have you done?” 
Engel explained. Powell immediately called up Beckman, 
who flew out to Pittsburgh, looked at this phenomenon, and 


said, “That is fantastic, can we have a copy of that?” And 
Frank Engel replied: “Westinghouse does not supply object ' 
code." 4i§ : 

J. A. N. Lee 

In fact, the story does not even end there. During 1 
the NCC session, William P. Heising, in discussing ?.•- 
the problems of developing a follow-on compiler to the 4 
original IBM 704 version, stated that the original code 
had been lost; all that was available was the object 
code! Perhaps the reason that Beckman did not supply 1 
the source code was that there was none! 

☆ ☆ ☆ 

Two examples of an individual’s memory and a resec - 
tion to it are illustrated here. 

There is an interesting, but little known, relationship be- . 
tween the first fortran compiler on the IBM 704 and the 
early development of operating systems. In 1955, what was 
probably the first operating system had been developed and 
was in use at the General Motors Research Laboratories; ; 
Called the I/O system, it was a three-phase system in that 
a batch of jobs was processed entirely with regard to input 
formats, then the entire batch was processed for execution, : 1 
and finally the entire batch was processed for output edn- 'di- 
version and printing. There were no higher-level languages 
in that system. 

Shortly thereafter, IBM released the first version of the 
fortran compiler as a set of programs on a magnetic tape, 
but without any listings of the source programs. The com- 
piler itself consisted of a short bootstrap record on the tape,' J 
followed by many short records, each fully aware of the .. 
position of every other record on the tape, so that when a 
new procedure was to be brought in by loading another - 
record from the tape, it was usually found by rewinding the 
tape and spacing out the appropriate number of records. ;^; 
Even this much organization had to be deduced without any 
documentation or listings. 

Jim Fishman at General Motors did this analysis by 
obtaining an octal dump of the entire tape. He very carefully ;> 
analyzed each instruction until he understood how the sys - 
tem worked. Without disturbing the order of the records, he 
then expanded some of them to include other components ., 
of what later became the excellent General Motors Research y 
operating system. Thus the bootstrap loader grew from 
about 20 instructions to several thousand when it became 
the assembler preceded by the bootstrap loader in the same • 
record. Later a relocatable loader was added, as well as other^ 
functions that we would now recognize as appropriate to an : 
operating system. All this while FORTRAN never knew what g 
happened! 

A couple of years later, we adapted this operating system '); 
to our needs, beginning a long history of operating-system . . 
development at the University of Michigan. 

Bernard A. Galler 

University of Michigan 

Our records corroborate the essence of Bernie’s anecdot* 
However, there was no need for an assembler in the Bi&m 
version of the F system since FORTRAN I object code c ouw f 
not be linked with other object code (except that object cards j 
punched by FORTRAN I when edited onto the IBM FORT - 
tape could be accessed by subsequent FORTRAN programs i 
a function). It was the entire F system itself which repte 
the first record of IBM’s fortran tape. Note that FORT 
issued a load-card sequence following each compile. 
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" y feature plus the “continuation cards” we placed in 
T; c ' arc j reader made this FORTRAN operating system pos- 

>-% 0 no te that computer job billing was a fair accomplish- 
ment in 1957 at GMR. using a computer-readable real-time 
flock. I believe the first such clocks in the industry were 
built by GMR and Westinghouse, Pittsburgh. They used the 
--ho entry hubs of the printer, and really were better than 
IB\f s first clock, on the 360 eight years later. It may be 
-bserved that GMR was not only the first site with a 
Computer operating system (I/O system) but also the first 
Ate with more than one operating system (I/O system and 
F jvstein), now apparently a perpetual encumbrance. 

I also recall the first University of Michigan modification 
to GMR's operating system. It consisted of replacing the 
■GMR" in columns 73-75 of all source cards with “UOM.” 

J. J. Fishman 

General Motors Research Laboratories 


☆ ☆ ir 


When JAN and I were developing the titles for the 
annotated FORTRAN bibliography in this issue, we 
decided to include some reviews of representative text- 
books such as C. C. Gotlieb’s 1961 review in Comput- 
ing Reviews of Dan McCracken’s text — the first text- 
book devoted solely to FORTRAN. We were in the 
process of trying to determine a set of criteria for 
reprinting a particular review of this sort, when JAN 
found a 1966 editor's note in CR. In an attempt to 
find the source and rationale for the policy statement 
in CR at the time, JAN wrote to Peter Ingerman. 


!n the year 1961, Computing Reviews published the first 
review of a fortran text (Dan McCracken’s) by Kelly 
Gotlieb. The review said, in pan, “Since each version [of 
fortran] has its own description, this latest work might 
redundant but it does have some definite advantages”! 
Five years later, in the September-October 1966 CR, there 
appears the following editor’s note: “In view of the extensive 
proliferation of textbooks on FORTRAN programming, it has 
been decided that, in lieu of full reviews, such books will be 
cited with a brief indication of intended audience and special 
Matures, as seen by the author.” 

At that time, Aaron Finerman was editor-in-chief and 
you were the editor for “programming.” Who promulgated 
this policy? And can you add anything to this story? 

J. A. .V. Lee 
Blacksburg, Va. 


(I suggest that before reading this letter, you attempt to find 
? ^cording of Maurice Chevalier singing “Ah Yes, I Remem- 
ber It Well” from “Gigi.”) 

The editor’s note that you quote is, to my memory, the 
result of a discussion that I had with Lee Revens [then 
Paging editor of CR]. 

. P r °blem that was encountered was that there were 
•ndeed a large number of FORTRAN texts being produced at 
t time, and the number of reviewers who were willing to 
ntinue to review them was vanishingly small. Lee Revens 
ssed with me the problem that he was having in finding 
"“ied reviewers, in the face of ever-burgeoning boredom, 
suggested that since fortran was no longer the only 
e m town, it might be reasonable to worry less about it 
n bad been done in the past. I agreed, and the editorial 

not « appeared. 


I guess from a historical perspective, the only real signif- 
icance was one of desperation in finding people who would 
be willing to review yet another “How I Wrote a fortran 
Compiler in Times Square for the FBI and Found God” text. 

Peter Ingerman 

Willingboro. N.J. 

☆ ☆ ☆ 

As a university instructor, I am always having to 
justify why I am so hard on my students for what they 
classify as a silly or trivial error. The next anecdote 
has dramatically improved my position. The path by 
which it arrived in these pages is typical of anecdotal 
retrieval. On April 10, 1981, R. Bharathy of Northern 
Michigan University wrote to Communications of the 
ACM regarding the following phrase in Tony Hoare’s 
1980 Turing Award Lecture, published in CACM (Vol. 
24, No. 2, 1981, p. 76): 

The story of the Mariner space rocket to Venus, lost because 
of the lack of compulsory declarations in fortran, was not 
published until later. 

Bharathy queried: 

I have not been able to locate anything in Communications 
of ACM circa 1963-64, but I am sure it must have been 
reported in Communications, and I would be grateful if you 
could let me know where I can locate further information 
on the matter. 

JAN located the following “Note on Program Reli- 
ability” by Jim Horning (ACM SIGSOFT Software 
Engineering Notes , Vol. 4, No. 4, October 1979, p. 6). 
The first American Venus probe was lost due to a program 
fault caused [3] by the inadvertent substitution of a state- 
ment of the form 

DO 3 I = 1.3 

for one of the form 

DO 3 I = 1,3 

The first thing to observe about this unfortunate incident is 
that the punishment exceeded the crime. Such a “small” 
fault to have a “billion dollar” consequence! But the chain 
was no stronger than its weakest link. The beauty and 
elegance that may have been in the program’s design, the 
methodology and software engineering that may have been 
used in its development, and the effort that may have been 
lavished on reliable hardware, all were to no avail when a 
single typographical error could destroy the correct func- 
tioning of the system. 

This example is not presented as an attack on NASA — 
which probably has one of the better reliability records 
among users of large software systems — nor as an attack on 
(just) FORTRAN — which is no worse from a reliability point 
of view than many newer languages— but precisely because 
the failure to detect this fault prior to use is so typical — 
only the visibility of the consequence was extreme. In a 
recent lecture reporting on his experience developing the 
tex system, Don Knuth (surely one of the great program- 
mers of our time) cited a rate (per thousand lines of code) 
of 40 faults undetected by the compiler and 12 faults unde- 
tected by all testing prior to release. 

Horning’s source “[3]” was G. J. Meyers, Software 
Reliability: Principles and Practices , New York, John 
Wiley, 1976, p. 275, as follows. 


Annals of the History of Computing, Volume 6, Number 1 . January 1 984 * 61 


FORTRAN Anecdotes 


In a fortran program controlling the United States' first 
mission to Venus, a programmer coded a DO statement in a 
form similar to the following: 

DO 3 I = 1.3 

The mistake he made was coding a period instead of a 
comma. However, the compiler treated this as an acceptable 
assignment statement because FORTRAN has no reserved 
keywords, blanks are ignored, and variables do not have to 
be explicitly declared. Although the statement is obviously 
an invalid DO statement, the compiler interpreted it as 
setting a new variable D03I equal to 1.3. This “trivial” error 
resulted in the failure of the mission. Of course, part of the 
responsiblity for this billion-dollar error falls on the pro- 
grammer and test personnel, but is not the design of the 
fortran language also partially to blame? 

The main reason that programming language design has 
an effect on software reliability is that professional program- 
mers spend more time examining existing programs than 
they spend writing new programs. The activities of debug- 
ging, maintaining, and extending programs are largely de- 
pendent on reading and understanding a program as it is 
represented in a programming language. Hence the design 
of programming languages does have a significant bearing 
on software errors. 


☆ ☆ ☆ 

The replacement of an IBM 704 by a 709 at Lawrence 
Livermore Laboratory led to the following account by 
William Lokke. 

1 have reason to believe the earliest FORTRAN on the 709 
(Serial 1) must have been seriously repressed during its 
development. As soon as the compiler arrived, I used it to 
transfer a code from the 704. To save time, I decided to 
temporarily replace one rather long program with the follow- 
ing dummy program: 

SUBROUTINE name 
COMMON list 
RETURN 

After thinking a very long time, the compiler tumbled out 
hundreds of instructions. It may have been thousands but I 
stopped the printer before it finished. The commands were 
complex— many index references, many symbols not in- 
cluded in the common list. As if the compiler had ever so 
much to say but no program to say it to. Shaken, I made 
sure from then on that all my dummy subroutines had at 
least one executable statement. 

William A. Lokke 

Laurence Livermore National Laboratory 
☆ ☆ ☆ 

Bernie Galler, who is a fine raconteur as well as master 
of ceremonies, took advantage of his role at the Pi- 
oneer Day FORTRAN banquet to recall other ways in 
which the emergence of FORTRAN affected human 
computers. 

Some years ago, I did a computation in which I computed 
the following value. It was n « (n — l)/2 and n was 10. If we 
do the arithmetic, the value should come out to be 45. It 
came out 40, so I began to look into why. After all, when 
you don’t have enough parentheses, operators of equal prec- 
edence go from left to right; if you did the computation, it 



should have been 45. Then I discovered that, in fact, the : 
optimizer was doing things so that the right thing was in 1| 
the register at the right time and the division came first 
Thus n — 1 being 9 divided by 2 using integer arithm*»«^iffi 


using integer arithmetic^ 
comes out 4. That is why the answer was 40. 1 wrote a letter^" 
to somebody (I don’t remember who) saying there was a bug . 
or something. The answer I got back was something to this 
effect: It is too complicated to change the compiler, so we 
will fix the manual. The next time I got a new manual I & 
looked for it, and inside the front cover was the following S 
statement: “Please be warned that mathematical equiva- 
lence is not the same as computational equivalence.” Peter 1 
Sheridan says he had something to do with that. 

We studied the fortran source-code listings to really ; 
understand what fortran did, because we were going to 
write our own compiler for another language. Bob Graham, 
in particular, studied the listings. We discovered that all 
those tables that were being searched were on the drum. -V; 
They were making one comparison per revolution, which v 
was understandable from the way the compiler was orga- ■/' 
nized. They didn’t know how big the tables would be. We T 
decided we could change that by keeping tables in core for ? 
as long as we could, and we made a faster compiler, etc. The - 
interesting thing is that searching those tables on the drum - . 
put a very heavy load on the drums. One of the things I r 
remember from working with General Motors was the report S 
that the GM fortran was working far better than the one . 
at Westinghouse because GM people had been riding their 
engineers much harder with respect to how the drums would •• 
be serviced. The Westinghouse fortran went down far 
more often than the GM one. (An interesting comment. 
nowadays. I m sure all of the IBM services are perfectly fine, v 
and nobody has those troubles.) It was a revelation that 
nobody had worked their drums that hard before, and FOR-' T 
tran did it. 


Bernard A. Galler 


☆ ☆ ☆ 


At the banquet David Hemmes gave the following V 
stream-of-consciousness account of life in the Backus/. •*. 
Berner territory at FORTRAN headquarters. 

As Bob Berner mentioned at the Pioneer Day session, we 
did the maintenance for the compiler. People would call me T 
from Omaha or Chicago and say, “Do any of these instruc- ijjg 
tions compile?” I wouldn’t know, so I’d run around and talk 
to John. We got on fine, but where could we go from there?; 

We put an ad in Scientific American. We needed program- '-A& : 
mers because fortran had to continue. There were no 
programmer-aptitude tests. There were no computer science 
departments in universities. We put a little horse head, a 
knight in chess, in the ad. and people applied for jobs. We 
got Arthur Bisguier, the chess champion of the United^' 
States. We got Sid Noble, the chess champion of the French | 
Riviera. Sid had been plucking chickens on the French J 
Riviera and he ran out of cash. We also picked up Bob Grill, 
who was a folk singer. And we picked up Flo Pessin from ; 
that ad. So we moved forward toward 709 FORTRAN, and j 
about that, time even Herb Grosch showed up. Now, let's.: 
have a little quiz: How many lines of code did Herb wnte£ 
Florence went on to model the computer smock for Harper *i 
Bazaar. I went on the Gary Moore Show, and did my income 
tax on an IBM machine. Meanwhile, back at the office, what 
do you hear? Castle, knight takes pawn, king to queen f our '’ j| 
David Hemmes 
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☆ ☆ ☆ 

At the banquet following the History of Programming 
languages Conference in Los Angeles in 1978, John 
Backus referred to the young woman whose early- 
morning habits inspired the FORTRAN team to arrive 
at work early and indirectly increased their productiv- 
ity until the work site was moved. During the planning 
period for the FORTRAN Pioneer Day, Walt Brainerd, 
.JAN ? Lee, and I [Hank Tropp] decided that since 
Pioneer Day was to be in New York City, we ought to 
be able to hire a woman of appropriate age to appear 
at the banquet and identify herself to John as that 
earlv-morning exercise enthusiast. When the NCC 
site was moved to Houston, we abandoned that prank. 
Here's the story, as told by John in Houston in 1982, 
followed by his previous “botched” version at the 
HOPL conference. 

1982 Version 

The last time I tried giving an anecdote was at the History 
of Programming Languages Conference, and I got all in- 
volved in some complicated tale about an anonymous person 
who contributed a great deal to our work, but, in fact, she’s 
not anonymous any more (rumor has it that her name was 
Dancer Nus). 

Two of our scholarly people decided that they would do 
>ome scholarly investigation and find out who the beautiful 
young woman across the street was who used to water her 
dowers before getting dressed. She had a very good influence 
on the project, because everybody came in very early to 
work. I never was able to make her acquaintance because I 
was a commuter and my train never got in early enough, but 
everytime I arrived at work, everybody else was always there, 
sort of gathered around the window. I made such a botch of 
the anecdote on that occasion that this is my last attempt. 

1978 Version 

One peculiar thing may account for the changes in produc- 
tivity that the fortran group experienced in its three years 
of work. It has to do with the strange locations in which we 
worked. We were shifted around from one small building in 
the area of 590 Madison Avenue, New York, to another at 
fairly frequent intervals. This seemed to affect our work 
habits in a strange way. We started out in the top of an 
an ”® x °I 590, next to the elevator machinery. We had to 
walk up the last flight because the machinery couldn’t get 
that last flight. From there we moved to a building on 
th Street— the oth floor of a small building. You had to 
Punch a time-clock when you worked for IBM in those days. 

ou had to punch in at 9:15 or you were in trouble. So 
everybody typically punched in at 9:14. 1 was a commuter at 
at time, and my train came in so that I did that pretty 
inti** l" • a ™ vec * just in the knick of time. After we’d been 
wh 1 t ” u ^ing on 56th Street for a while, I noticed that 
en came in, everybody was there — and apparently had 
jjr n ther ® f° r some time. This practice went on. I finally 
acro °ver6d the reason for it. Someone confided in me that 
beh S Vu street fr° m our building was an empty lot and 
of th t ^ at WaS t ^ le ^ ac k of an apartment building. In one 
an J? apartments lived a young woman who slept without 
very p° V ° n ’ used to get up in the morning and dance 
xuberantly for a while before going to work. So that 


was a period of great productivity because everybody came 
in very early and the show was over after a while, and 
everybody settled down to work long before starting time. 

But then we were moved to other buildings. The first one 
we moved to overlooked the dressing rooms of the Jay 
Thorpe department store. Then we moved to another build- 
ing that overlooked the dressing rooms of Bonwit Teller. 
For some peculiar reason, people spent an awful lot of time 
at the windows, and during this period our productivity 
seemed to decline considerably. Finally, we wound up in a 
building that had no view at all. We finally managed to 
complete the project, despite all the hazards along the way. 
☆ ☆ ☆ 

JAN Lee was not content just to probe the memory of 
fortran participants. He decided to check a variety 
of written and film records and came up with the 
following potpourri of claims, predictions, and bare- 
faced statistics. 

SHARE III, Nov. 10-11, 1955. Agenda Item 13, Com- 
pilers; FORTRAN 

Backus (NY) made a progress report on fortran He 

expects that in its first edition fortran will include eight 
to ten thousand instructions, which will be coded by January 
1st [1956]. ... He estimates that it will be completely 
checked out sometime in February. . . . Minimum compo- 
nents will be one 4096-word core, four tapes, one drum box. 
It is estimated that it will take six minutes to produce one 
thousand symbolic instructions. 

SHARE V, May 9-11, 1956. Item 7, fortran 
J ohn Backus of IBM World Headquarters reported on for- 
tran. . . . [It] will be ready for customer use by early August 
1956. . . . The system will have taken fourteen man-years to 
write and check out. . . . The program will be comprised of 
approximately 19,800 instructions. . . . There are currently 

twelve people working on the project The minimum 

machine will be 4096-word core, four tapes, and four logical 
drums. ... For every fortran instruction written, five to 
twenty instructions will be generated . . . resulting in a 
reduction in coding time by a factor of from three to thirty! 

Actual Delivered Processor, April 1957 (from WJCC 
Proceedings, February 1957) 

18 man years have elapsed. . . . [It] would reduce the coding 
and debugging time to one-fifth of the job it had been. . . . 
One job [was] programmed in four hours, using 47 FORTRAN 
statements . . . compiled in six minutes, producing 1000 
instructions. 

The processor contained 24,000 instructions, accord- 
ing to the table of instructions. 

Experience by December 1957 (from internal IBM 
memorandum from Steve Jamison) 

1. Good programmer can write 7 fortran statements per 
hour. 

2. The average fortran statement gives rise to about 9 
machine instructions. 

3. Compiles an average of 15 statements per minute (giving 
810 instructions generated in six minutes). 

4. It is about 5 times quicker to program using FORTRAN 
than using SAP. 
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5. The cost to prepare a machine instruction cut to one- 
fiftieth of the previous cost. 

From NY Education Center Film, 1958 

This system has been developed ... at a cost of S475.000 

and represents 29 man-years of effort. 

By the time of this film, fortran existed for both the 
IBM 704 and the 650; it is not clear if both are included 
in these figures! 

☆ ☆ ☆ 

It is impossible to probe the beginnings of an event of 
the magnitude of FORTRAN without the name of John 
von Neumann. Cuthbert Hurd and John Backus have 
reasonably established that the FORTRAN project got 
a green light in about December 1953. At that time, 
von Neumann was a consultant to IBM and worked 
closely with Hurd, who had hired him. Daniel Leeson 
first suggested that von Neumann had attended a 
meeting at which fortran was discussed. JAN and I 
asked Hurd whether or not von Neumann had any 
link to the FORTRAN project in its early stages and/or 
if he had even expressed his feelings about the need 
or importance for such a project. Hurd did remember 
an early meeting on the subject of language develop- 
ment which von Neumann attended, as had John 
Backus, Frank Beckman, and John Greenstadt, but 
he could remember no specifics on any aspect. On 
reflection, he thought that von Neumann had not been 
impressed. 

As JAN and I independently and casually discussed 
this subject with others, most of what we learned was 
a continuation of the general lore on the legendary 
von Neumann. 

What, would he have needed an automatic programming 
language for? He wouldn’t have seen the need any more 
than he saw a need for machine storage memory — he could 
do so much in his head. 

John Greenstadt 
Palo Alto. Calif. 

JAN contacted Frank Beckman about the von Neu- 
mann-Hurd-Beckman-Greenstadt meeting and was 
referred to a published account. 

Sometimes [sic] in 1954, IBM . . . sought some outside 
confirmation ... of its investment . . . [in] FORTRAN. ... A 
presentation of the language was given to . . . John von 

Neumann He seemed to the author to be somewhat 

bored by the proceedings and, yes, he did at the end acquiesce 
in a recommendation that the project be pursued but, on 
theoretical grounds, seemed to dismiss the whole develop- 
ment as but an application of the idea of Turing’s “short- 
code.” 

Frank S. Beckman, “Mathematical Foundations of Pro- 
gramming," Reading, Mass., Addison-Wesley, 1980 
Beckman, in personal correspondence, also states: 

I would not describe his reaction as being unduly negative — 
somewhat apathetic perhaps. . . . 

In general von Neumann was not an enthusiastic sup- 
porter of automated programming aids. ... I have always 



felt that since he, himself, did not require such aids in writan* 
programs, he could not empathize with the typical producl 
tion programmer. 

Frank S. Beckman 

/if'* ' 

Unfortunately, Greenstadt had left the meeting by the 
time fortran was discussed and thus is unable to 
confirm this anecdote. When questioned about von 
Neumann’s health at that time, and whether this had " 
any effect on his apathy, Greenstadt said: “He seemed 
so dull.” Greenstadt pointed out that at about the 
same time von Neumann, after only about 30 minutes 
of discussion, said that the solution to a particular 
problem in partial differential equations was not fea- 
sible. It took the rest of the world 20 years of trying 
to show that the problem was workable, after alL 
“Maybe we’ll never know when, or precisely how, von 
Neumann’s fatal illness affected his powers” said 
Greenstadt. 


To close this section on fortran anecdotes, we 
quote Greenstadt’s reflective view of the changing 
attitudes toward fortran. 

I was not really aware of how John collected his cadre of 
some of the most original and capable programmers avail- 
able. but I do recall a couple of episodes which occurred 
much later in the development, when the end was in sight. 

In one case, while I was on a trip out West, a very well- 
known and capable programmer, in the course of a discus- . 
sion on the relative merits of fortran and pact (a system 
being developed by a group of western installations), said to • 
me with great conviction, “Backus has bitten off more than 
he can chew!” This was the consensus among those “in the 
know” at the time, so John Backus was definitely swimming V 
against the current all along. 

On another occasion, at the time that fortran was to 
have been completed (it took another year to finish it), one . 
of the IBM executives very closely connected with the FOR- . 
tran group’s efforts (and %vho should have known better} ■ 
asked me casually, “What do you think of the FORTRAM -■-! 
fiasco?” If one of John Backus’s supporters thought so ill of 
the effort, it is not hard to imagine how negative the atti* : > 
tudes of less technically oriented people in IBM (who make 
up the power structure) must have been. My reaction to the. 
question was that I didn’t see why it was a fiasco, because. ^ 
what was so unusual about a large programming effort being ^ 
a year late (even today)? 

John Backus himself was not immune to feelings orj£& 
discouragement and even despair, in the face of these doubt--:? 
ers, and at one time even considered handing the whole v . 
project over to someone else to finish. But he took heart 
again, after realizing that fortran and John Backus wdnE® 
almost synonymous, and went on to complete (with 
talented group) one of the most remarkable pieces of 
gramming in computing history. It is ironic that, at a 
ing only one year after fortran had been completed 
made available by IBM, I heard an arrogant young 
(discussing compilers, translators, etc.) refer rather patron^. 
izingly to “conventional languages like FORTRAN”! In 
year after everybody was sure it was impossible, it 
“conventional”! 

John Greenstadt -W3B& 
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FORTRAN Ceiebration at IBM Santa Teresa 
Laboratory 


To help celebrate the 25th anniversary of FORTRAN, 
the first widely used high-level programming language, 
IBM's Santa Teresa Laboratory (STL) in San Jose, 
California, declared July 12-16, 1982, to be Fortran 
Week. 

Events during the week included the exhibition of 
two displays: the fortran historical display shown at 
the 1982 National Computer Conference in Houston 
and a display that depicted the role of IBM’s General 
Products Division. A special edition of the lab’s em- 
ployee newspaper Reflections featured an article by 
John W. Backus, who led the original FORTRAN de- 
velopment effort, and quotes from local IBMers with 
extensive experience with the language. 

On Tht irsday, July 15, laboratory employees were 
invited to partake of anniversary cake and coffee 
during lunch, while an old-fashioned jukebox played 
songs from the late 1950s and early 1960s, the era in 
which fortran was invented. Later that afternoon, 
about 500 lab employees and guests filled an audito- 
rium to hear Cuthbert C. Hurd, John Backus’s man- 
ner at the time fortran was devised, and others talk 
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about the language. The film featuring interviews with 
Hurd, Backus, and other FORTRAN pioneers developed 
for the NCC exhibit was shown, and attendees re- 
ceived commemorative balloons and posters as they 
left the meeting. 

FORTRAN Activities at SHARE Meeting 

The fortran exhibit displayed at NCC ’82 and the 
IBM Santa Teresa Laboratory was subsequently 
shipped to the SHARE 59 meeting in New Orleans, 
August 22-27, 1982. At a special fortran session 
chaired by John Ehrman, Elliott Nohr of IBM spoke 
about the early days of fortran and how SHARE 
and IBM worked together to make it more widely 
used. We are presenting an edited version of Nohr’s 
paper with SHARE’S permission. 

Today I would like to give you a little history on the 
development of FORTRAN and SHARE’S involvement with 
the language. Before I start talking about FORTRAN, I would 
like to talk about the environment from which FORTRAN 
emerged. First, no large collection of programs was available 
from IBM or anywhere else. Numerous assemblers were 
used — each one tailored to a particular installation. Each 
installation had its own subroutines, and each library rou- 
tine was written in assembly language; most of those pro- 
grams were written entirely at the installation. A set of 
binary-to-decimal and decimal-to-binary conversion pro- 
grams were needed at every installation, and most people 
wrote their own. Little information was shared among in- 
stallations. In 1955, when the 704 came out (just about a 
year and a half before fortran), the users of the 701 (all 
20) were called together by the local IBM salesman in Los 
Angeles to see if they would share some of the burden of 
recoding their 701 programs for the 704. They decided their 
time would not be well spent if each user wrote an assembler 
program, a square-root routine, and the subroutines. There 
was an effort in Los Angeles to develop a system called 
PACT. PACT was a joint programming effort among a 
number of volunteers from different companies, but there 
was no real centralized development. Each group had to wait 
for others in the group in order to get the whole system built 
and checked out. During this time, SHARE heard of the 
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Institutionalization of 
FORTRAN 

JEANNE ADAMS, CHAIR 


Early FORTRAN User Experience 

HERBERT S. BRIGHT 


I want to mention a little-known aspect of how West- 
inghouse-Bettis, a nuclear-power-reactor development 
laboratory, together with a lot of other groups who 
ultimately became known as “the nuclear-codes 
crowd,” got interested in large-scale computing in the 
middle 1950s. 

Systems of elliptic partial differential equations are 
used to describe fixed-geometry nuclear-power reac- 
tors for criticality calculations. One group, reputed to 
be the world’s “outstanding authorities,” investigated 
the use of digital computers to perform such calcula- 
tions by relaxation or successive-approximation tech- 
niques. They concluded on theoretical grounds that 
the rate of approach to a correct solution, which must 
decrease with problem size, went to zero for numerical 
models of order 600. Using what was then the world’s 
most powerful computer, the NORC (Naval Ordnance 
Research Calculator), they performed experiments 
that seemed to support that conclusion. 

Problems of the order 2500 were already in use for 
two-dimensional reactor design work, represented by 
passive electric-network models. Using a special-pur- 
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pose analog simulator, one such solution took 
six weeks of day-and-night chain-gang-style Iabotfl 
several skilled technicians. The 600-limit “proof jf 
pretty well convinced the reactor designers that dig 
computers weren’t going to help them. 

A team of mathematicians, headed by Eliza 
Cuthill at the U.S. Navy’s David Taylor Model'!} 
near Washington, concluded that the proof applit 
the mathematical technique instead of to the probl 
Using a new technique, they wrote a program to ,sj& 
problems up to order 2500. 

The machine they had available was a ONiyji! 
computer that had about as much memory as a mix 
pocket-size key-driven calculator and exeqj 
roughly 1000 instructions per second. The prog 
took between 30 and 40 hours of machine time*] 
solution, but it ran! Results were correct and usa§ 
It was used to design several reactors. 

Although Betty would never have named anytBi 
, after herself, her 2500-point program became knffl 
as the Cuthill Code — now a household word in 
nuclear-codes community. Without such a sue 
demonstration that the world’s outstanding 
ties could be wrong, there would have been no- ea 
large-scale nuclear codes. The demand for morefli 
more powerful computers would not have gain 
major push. 

When I recently discussed this development ™ 
distinguished computer historian, I was startle; 
learn that few people in other fields of applie 
ematics have even heard of the work. As of todi 
will no longer be able to make that statement 
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Criticality calculations gave information for a par- 
ticular design and a particular set of operating condi- 
tions about the extent to which the chain reaction was 
supercritical. These calculations took a lot of machine 
time, and memory space was extremely expensive, so 
they were hand-polished to maximum efficiency in 
time and space. In 1957 one- and two-dimensional 
versions were running on an IBM 704. 

To simulate the reactor core through its working 
lifetime, it was necessary to perform a depletion or 
burnout calculation using the output of a criticality 
calculation to determine at each point inside the core 
what neutron bombardment had done to the core 
materials. That turned out to be an enormously com- 
plex problem. For a 250-point one-dimensional solu- 
tion that was running at that time, for example, the 
depletion calculation included 30,000 lines of assem- 
bler code. The core designers were planning two- and 
three-dimensional codes. 

Understanding of the behavior of the materials un- 
der nuclear bombardment grew rapidly. This further 
complicated the coding problem, which, of course, was 
accompanied by a huge maintenance problem. The 
question arose: Could we do that much coding and 
maintenance? 

As if that weren’t enough pessimism, the people in 
the Mathematics Department at Bettis Laboratory 
were pessimistic about the still-fetal FORTRAN. We 
had expected that FORTRAN, presuming it would be 
available some day, could never construct code that 
was really efficient, either in time or in space. Our 
intention to take a look at FORTRAN was accompanied 
by the assumption that it was going to produce rotten 
code — as a matter of fact, on occasion it did. Some of 
the fortran object code was amazingly efficient, but 
we hadn’t yet learned how to predict or control that 
aspect of compiling. 

Fortunately, the depletion calculations only got ex- 
ecuted once per time step. Unlike the criticality cal- 
culations, although they took a lot of code, they didn’t 
have to be efficient; they only had to be correct. To 
our delight, FORTRAN produced correct code, and the 
amount of labor required to debug and maintain the 
tode— and even to change it substantively — was re- 
markably small. 

In the first issue of the Annals * I described a 
Fortran test problem that was part of a depletion 
calculation. If the solution was correct — even if its 
tcsulting code was inefficient — it would be important; 
this was not just an exercise. The expression shown 
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Figure 1. Notes on Gamma (Tau) code. 


for gamma in Figure 1 was computed by incrementing 
several variables to generate a table for what was 
known as “gamma of tau for the inhour formula.” The 
independent variable was the amount of time each 
material was in the reactor core under neutron bom- 
bardment. The result was used to calculate the behav- 
ior of each point in a geometric array of material as a 
function of time. The story in the Annals gave some 
operating details of our first test of FORTRAN using 
that calculation. 

Late one Friday afternoon — the Friday before a 
SHARE meeting — the Bettis mailman showed up with 
an unmarked box of cards with no documentation. 
Lou Ondis, Ollie Swift, and I were standing in a 
hallway when the mystery package came along. Un- 
fortunately Jim Callaghan’s carpool had already re- 
moved him from the scene. Ollie had written a report 
specifying the “gamma of tau” calculation, on the basis 
of which Jim had written a FORTRAN test program. 
Jim had only this shiny gray thing marked “Fortran 
Programmer’s Manual,” a sort of fat brochure that in 
retrospect was incredibly accurate in comparison with 
typical modem documentation. Jim had spent about 
one afternoon writing this program. To give you a 
comparison with our previous methods, we later esti- 
mated it would have taken about two weeks to have 
written this amount of code in assembly language and 
another week or two to debug it. 

Lou suspected that the anonymous box of cards 
might be the overdue fortran compiler. Ollie sug- 
gested a way to find out. Hang a full set of 10 blank 
tapes on the 704 and act as though we believed this 
was, in fact, fortran. Load the compiler and the 
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FORTRAN DIAGNOSTIC PROGRAM RESULTS 


B# 


29 GO TO ( ?00»210»220»230#?40*250*260*?70#?SO*290#3nO«310»T?0»330)M •*’ 

0S065 SOURCE PROGRAM ERROR. THIS IS A TYPE-GO TO ( )#I-RUT THE RIGHT PARENTHESIS IS NOT FOLLOWED RY A COMMA 1 


END OF DIAGNOSTIC PROGRAM RFSULTS 


Figure 2. Gamma (Tau) diagnostic printout. 


(Ai/S S*MLCBP! 


. 0*1 . 0*2 

0.1922** 0.1923*0 0.192*13 
0.192113 0.192317 0.1924*1 
0.192121 0.1922** 0.19*3*9 
0.1920*9 0.192193 0.192327 
0.191997 0.192131 0.19224* 


^OEjPRlMElTAU.OELTA **) AS oStJ IN 1M*0UM FORMULA 
VALUES OF OCLTA 2* (uQhO~ 

•0*3 .0*4 .0** .0*4 .0*7 

0.192447 0.1927*0 0.192913 0.193044 0.19317* 

0.192**4 0.19271* 0. 192**1 0.1929*3 0.193114 

0.19**22 0.1*24** 0.1927** 0.192921 0.1930*3 

0.192440 0.19**93 0.192724 0.19 **>• 0.192991 

0.19239* 0.192*31 0.192464 0.192794 0.19292* 



0.192*** 0.192**7 
0.192493 0.192*2* 
0.192431 0.192*43 
0.192349 0.192*01 
0.192307 0.192439 


Figure 3. Gamma (Tau) output (first part of 28 pages). 

source program — it did not require input data, because 
one set of test values was built in — and attempt to 
compile, load, and execute. 

Lou got through those processes successfully. After a 
few minutes of machine activity, we wound up with a 
single, printed, English-language diagnostic of incred- 
ible specificity. Figure 2 gives the “diagnostic program 
results.” 

We looked at the card. The diagnostic was right! 
Lou reproduced the. card with a comma stuck in the 
right place. We recompiled. After a little whiff of 
computing, there came something like 28 pages of 
output (see Figure 3). There were several errors in our 
use of Roy Nutt’s FORMAT phase, but the results rang 
like old crystal. We random-spotchecked about 15 
values. I was convinced that all of the output was 


essentially good to the six decimal digits printed, 
remarked in the Annals (our story had first T 
published in 1971) that a couple of hundred comp: 
fixes down the road, it was hard to believe its 
happened. I still feel that way. 

John Backus has commented that although his F 
TRAN group intended to distribute the first FOR 
compiler in binary-card form, only one or two 
actually got punched. They used up several repr 
ing card punches per binary deck produced; the 
chinery couldn’t stand the mechanical load. 

The fact that the newborn FORTRAN got to US) 
the last working day before a SHARE meeting 
that Jim had produced a workable test program^ 
was ready to try the compiler — represented inc 
blind good luck. 
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Early FORTRAN at Livermore 

ROBERT A. HUGHES 


The Lawrence Livermore National Laboratory 
(LLNL), located about 40 miles due east of San Fran- 


Author’s Address: R. A. Hughes, Lawrence Livermore National 
Laboratory, P.O. Box 808, Livermore, CA 94450. 



cisco, is a facility for nuclear research and w 
design. Being only slightly younger than the m 
digital computer, LLNL’s history is closely ti 
that of the computer industry is that it is: L - , 
1. A leader in the application of computers; 
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FORTRAN) to the solution of large-scale scientific prob- 
lems and to major systems software implementations. 

2 Staffed by experts in both software and hardware 
'design. 

3. One of the largest concentrations of computing 
power in the world, housing both the Octopus Com- 
puter Network and the Magnetic Fusion and Energy 
Computer Center. The latter is a national network. 

LLNL has a user community of 8000 employees, of 
whom 4000 are scientists or engineers. It has 2000 
time-sharing ter min als, and works on scientific appli- 
cations in mathematical physics and biomedical re- 
search. Its system software consists of operating sys- 
tems, language processors, and computer graphics. 

Computing at LLNL began with the first commer- 
cially available machines, the UN1VAC I in 1952 and its 
successors, the IBM CPC, an IBM 701 in 1954, and 
two IBM 650s. There were some early compiler efforts. 
K1 and K2 were experimental algebraic compilers for 
the IBM 701 based on flowchart algorithms. K3 was 
an IBM 704 compiler designed to maintain the integ- 
rity of conventional mathematical notation. It re- 
quired three cards per statement, the first and third 
being used for exponents and subscripts. It was named 
K3 for “Kent Ellsworth and the world’s third compi- 
ler.” K3 had a successful first run. It then became the 
world’s second Spruce Goose in the wake of FORTRAN’S 
growing popularity. 

Interest in fortran began in 1955, when IBM 
announced plans for an automatic coding system for 
the IBM 704 (LLNL eventually had four 704s). In 
those early days, LLNL was one of the few organiza- 
tions that used computers and was aware of the 


fortran project. Sidney Fernbach, head of the Com- 
putation Department, spearheaded an effort to gain 
firsthand knowledge of fortran’s implementation 
and potential as a programming aid. I was sent to New 
York in the summer of 1956 to work with the FORTRAN 
development team, led by Backus. 

From the advent of FORTRAN in early 1957, an 
extended fortran called lrltran became the most 
used programming language at LLNL. It was typically 
used to compile compilers (FORTRAN-FORTRAN) and 
to maintain up-to-date software for succeeding gen- 
erations of LLNL’s large mainframes. 

The first fortran-fortran was that of IBM 709 
(LLNL had two in 1958) fortran used to generate a 
fortran compiler for the CDC 3600 (two in 1963) — 
the first lrltran compiler — with no extensions to 
the language. The first two extensions appeared with 
the Livermore Automatic Research Computer (larc) 
(1960), a decimal machine from Remington Rand con- 
temporary with the IBM 7030 (Stretch). The larc’s 
FORTRAN compiler came from the new Computer Sci- 
ence Corporation and allowed a parameter statement 
with symbolic names for declarative constants, and 
alphanumeric and numeric statement labels. 

Early FORTRANs lacked mixed-mode arithmetic or 
byte declaratives; the latter shortcoming was decried 
by system programmers who felt “ betrayed” by the 
language designers, lrltran included these features 
and many others. IF THEN ELSE was added in 1977. 
Most of lrltran extensions are now “standard” un- 
der ANSI FORTRAN 77 specifications. Thus, after years 
of new user comments such as, “That’s not fortran,” 
LRLTRAN is again FORTRAN (well, almost). 


The Emergence of FORTRAN IV from FORTRAN 
WILLIAM P. HEISING 


Hy subject is slightly broader than the emergence of 
W fortran ii to 7094 fortran IV. I’m going to talk 
“out the evolution of 704 fortran during the period 
i 1957 to 1964 from my personal viewpoint. During 
“08 period I had various responsibilities in connection 
w >th Fortran. 

j fi rst responsibility was to assist on the transfer 
0 the fortran project from the Programming Re- 


^ Corporation, Neighborhood 


search Group under John Backus to the Applied Pro- 
gramming Department. Later I was manager of 7094 
programming, and still later I was responsible for 
coordinating fortran processor implementations 
within IBM. In 1957 the status of fortran was that 
the initial compilers were completed by the Program- 
ming Research Group, which had embarked on a 
significant improvement called fortran u that has 
enabled users to break up the program — a large 
application — into independent compilations. This was 
an important advance to which attention should be 
called. In fact, it was the genesis of many of the linking 
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loaders we have today. The idea of having an 
application program written not as the output of a 
single compilation but of many was new. It greatly 
expanded the possible use of FORTRAN because it 
meant that if some small part of the application 
required assembly-language programming, it could be 
done without writing a separate routine or function in 
the FORTRAN language. 

When I became involved with the Applied 
Programming Department, there were approximately 

10 people to take over the work of Backus’s 
Programming Research Group. Most of these people 
were capable but junior in experience in programming. 
Our first responsibility was to learn the structure of 
the compiler. Backus’s group had an informal 
management style, and there were some things that 
bothered us a little. For example, the different sections 
were written in two different assembly languages — 
certain sections in one and certain in the other. When 
we finally got Section 2, the Programming Research 
Group had lost the symbolic code so it came over to 
us in absolute. 

The most important initial project undertaken in 
Applied Programming was to get a version ready for 
the IBM 709, which had been announced in January 
1957 and was first shipped late in 1958. Because the 
group was new, a minimum number of changes were 
made in order to make FORTRAN operative on the 709. 
This machine had different input/output, and the 
configuration we chose to support was 8K main 
memory (instead of 4K) with a drum. The 8K main 
storage meant we had to be a little bit careful in 
shoehorning everything into storage. 

The original plan for the 709 programming support 
was to have a SHARE Operating System (SOS) 
designed by the most experienced users in SHARE. It 
was basically a design to surround the assembly- 
language program with some nice debugging tools. One 
group in programming would work on SOS, and the 
FORTRAN work would go on in parallel. The initial 
thinking was that we would integrate FORTRAN within 
SOS. We ran into schedule difficulties. There were 
some technical difficulties, too, in that the FORTRAN 

11 approach of modular programs was not well matched 
with the format of the deck of SOS. There was some 
allowance to match the two, but I don’t think all the 
technical aspects had been worked through. In any 
case, we weren’t able to integrate. The first 709 
fortran came out as a stand-alone system, not within 
SOS, and used a loader very much like the original 
linking loader of the FORTRAN II system on the 704. 

The 704 and 709 FORTRANs were successful quite 
early — especially fortran II — but the penetration on 
users, so to speak, was rather uneven. The most 
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experienced users (who dated from the days of 
IBM 701) tended to retain assembly-lai 
programming, and the newest and least sophistii 
newcomers to computing were most frequ 
fortran users. Nonetheless, the technical 
fortran was sufficiently sound that usage was 
snowball going downhill. . j . 

Soon there were hundreds of customers '.i 
hundreds of suggestions for improvements, 
would find bugs and send them in — not only 
reports, but in many cases the fixes would come’ 
along with the reports. Many suggestions applii 
such matters as improvement of diagnostics 
practical things — and it was as if there were hurt 
of people working on improving FORTRAN 
suggestions just poured in, and we put them in as 
as we could. 

A significant event occurred in 1958. The Ge 
Applied Mathematics Society (GAMM) proposed 
the Association for Computing Machinery (ACM) 
an international algorithmic language be devel 
and SHARE requested that Backus be its repi 
sentative. He participated in that effort and gave a 
portinthefallofl958.Asa result of this report, St 
was very enthusiastic about the possible future; 
ALGOL. In fact, SHARE went so far as to pass 's 1 
resolution requesting IBM to implement ALGOL. 

During a period of about a year and a half when 
were making minimal improvements on FORTRAN,? 
were also working up an ALGOL experimeni 
compiler. After about two years, IBM and S 
jointly realized that ALGOL was not going to supe 
fortran, and that we should look toward lo; 
range improvements in FORTRAN. We decided to cl 
up FORTRAN; this was the basis of the transition 
FORTRAN II to FORTRAN IV. The cleanup consisted pg 
a lot of details such as getting rid of mac 
dependent irregularities of the language, 
introducing and straightening the treatmen 
common and equivalence so that customers 
have to have special courses on how to 
EQUIVALENCE statements. Many changes 
planned. 1 ib : 

One important limiting factor, of course, was 
we wanted customers who had FORTRAN II p 
to be able to preserve them. SHARE plannedj 
wrote a translator written in FORTRAN to 
from fortran ii to IV. Don Moore, Jay Allan®; 
Paul Rogoway wrote that program,* and it was 
successfully on the conversion of FORTRAN n to 
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•J. J. Allen, D. P. Moore, and H. P. Rogoway, “SHARE 
Fortran Translator (SIFT),” Datamation 9, 3 (March 1963), 
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■p,e Impact of FORTRAN Standardization* 

MARTIN n. greenfield 

Almost exactly five years after the delivery date of the 
grst FORTRAN compiler, in May 1962 a committee was 
commissioned to develop a standard for the language. 
As we celebrate the 25th anniversary of fortran’s 
implementation, we can also celebrate the 20th anni- 
versary of the start of its standardization, fortran 
was the first language to become a national standard. 
Once formed, any standardization activity becomes 
the focal point for discussions of the plans, meaning, 
interpretation, revision, and extension of the lan- 
guage. In short, it is where the history of the language 
unfolds. 

Twenty years of events in the history of a language 
cannot be dealt with in a short talk. For those inter- 
ested, I have tried to recount the chronology of FOR- 
TRAN standardization in my paper in the conference 
proceedings. In particular, I tried to supply the names 
of those deserving credit for their many contributions. 
I also discussed how we handled many of the problems 
encountered in that pioneering effort. 

Instead of rattling into history, I would like to relate 
what I believe was the major impact of the standard- 
ization. Prior to standardization, there were relatively 
few FORTRAN implementations. Higher-level language 
usage was still considered just another tool. I believe 
standardization played an important and significant 


Author's Address: M. N. Greenfield, Honeywell Information Sys- 
tems, 300 Concord Road, Billerica, MA 01821. 

•See “History of Fortran Standardization” in NCC Proceedings 
(1982), pp. 817-824. 


role in elevating that status. Standardization provided 
a stamp of approval and a level of. acceptance and 
stability. The characteristics of the language would no 
longer be subject to the whims of a single organization. 
There would be an industry-wide voice in the defini- 
tion of features and the timing of their introduction. 
This stability was a prerequisite before many vendors 
and other implementors would undertake the large 
multiyear investment it took in those days to produce 
a marketable FORTRAN system. Long before the com- 
pletion of the work, the impact of the ongoing stand- 
ardization provided much of the impetus that led to 
the huge expansion of the number of implementations 
that followed. Shortly thereafter, all systems large 
enough to support a fortran system were expected 
to have one. fortran had graduated from being an 
important higher-level language to being a common 
programming language. 

This advance broke through many key barriers. It 
took programming out of the hands of the few. Pro- 
grammer skills became portable and not tied to a 
single system. It freed the user’s programming invest- 
ment from its ties to one type of equipment and 
vendor. It also freed vendors from ties to their older 
architectures because they could provide compatibility 
through the language. All of this contributed heavily 
to the huge expansion of our industry. Standardization 
was a major factor in making all of this happen. We 
can take justifiable pride in knowing that it was the 
pioneering effort in the standardization of the FOR- 
TRAN language that led the way. 


The Early History of FORTRAN Publications 

DANIEL D. McCRACKEN 

During the period of the fortran project, I was 
Programming and teaching programming for General 
Electric, mostly in assembly language on the IBM 701 
®nd 704. I visited John Backus sometime in that 
Period, at the old 56th Street office, but we have met 
*o many times over the years that I can’t remember 
now exactly when that was. 

* Address: D. D. McCracken, 160 Cabrini Boulevard, New 
i T «k,NY 10033. 


I learned fortran during my brief stay at the New 
York University-Atomic Energy Commission Com- 
puting Center, working from IBM manuals that I can 
no longer locate. People in those days sometimes 
sneered at IBM manuals, but I certainly had no prob- 
lems with that set. 

In 1960, after I went out on my own as a consultant, 
my first major writing job was to prepare an expository 
manual on the Honeywell Algebraic Compiler. This 
was a close relative of fortran; the compiler was 
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written by the Computer Usage Company under the 
direction of Asher Opler. I learned a great deal about 
FORTRAN and writing from that experience, which 
made it much simpler and faster to write my own book 
a little later. 

The rest of what I would like to say I think I can 
best organize by quoting a few sentences from letters 
I have found in my files from the period. 

A letter dated November 1, 1960, addressed to 
Walker G. Stone, my editor at Wiley at the time, 
proposes that I write a book on FORTRAN. The sen- 
tence that interests me says, “For the proper book, I 
have no difficulty imagining an initial sale of 15,000 
in the first two years, and a steady sale of 5000 per 
year after that for the indefinite future.” There is an 
undated comment on the side in my handwriting that 
says: “Well . . . ,” as though I thought that I had been 
pulling the wool over Walker’s eyes. Part of my rec- 
ollection of that period is that Walker had a lot of 
trouble selling the idea of a FORTRAN book to Wiley 
management. The question was, “Why would anyone 
pay for a book when IBM gives manuals away free?” 

In recent correspondence, Walker says it wasn’t really 
that bad. There was simply a feeling that the price 
would have to be rather low and that there would need 
to-be high volume and a lot of promotion to compete 
in such a market. (The initial price was $2.95. Have 
you bought a computer book lately?) 

The next letter is a copy of a sort of purchase order 
that I wrote to the manager of data processing at a 
General Electric department where I ran a couple of 
programs in FORTRANSIT on their IBM 650. I agreed 
to pay $46 per hour for the machine time. My most 
vivid recollection of that occasion is going up to Pitts- 
field, Mass., with a couple of decks, trying to run 
them, and getting a message that must have been 
something like, “undefined external reference,” or 
however it was phrased in those days. When I prodded 
the right wizards, the response was approximately, 
Sine and square root! You didn’t tell us you wanted 
any functions!” As a matter of fact, only a couple of 
the programs in the subsequent book were ever run. 

It still terrifies me to think that I did that. As you can 
imagine, the first printing of the book had lots of 
errors. 

The next letter is dated January 30, 1961, and reads 
in part: 

Dear Dan: Best wishes on your forthcoming book. 

Thanks for including me on your list of preferred first 
readers. I would like very much to give you all the help I 
can. Unfortunately, I must now disqualify myself from 1 
the task of an objective commentator since I have lately '• 
been working on a somewhat similar manuscript. The 1 
degree to which our ideas overlap or conflict is not clear : 
since I have not read your text but it is clear that we < 
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have similar objectives and somewhat different ways' 

going about the work. 

It was signed by Elliott Organick, who explain! 
me in recent correspondence that the work in quest! 
was indeed just about simultaneous with mine, eif 
he had started a little earlier. I might say in pa§gj 
that he gives a large measure of credit to his a 
tion with the Ford Foundation project on the 
computers in engineering education at Michi: 
having gotten him started. 

The first edition of his book was published by tl 
Houston University Computing Center, a little bejl 
mine. Houston University Press did not exist at t) 
time, so I have maintained a left-handed-third-bh 
man-on-a-rainy-day kind of record by saying K 
mine was the first commercially published FORTTf^ 
book. Elliott’s book was commercially published 
Addison-Wesley in 1963; it is, of course, a veryT3 
book, with several subsequent versions of which Lbft 
Meissner has been a coauthor. 

The last letter I want to quote is dated Septet 
5, 1961, again addressed to Walker Stone. “I w as 
course pleased to get the copy of the fortran bot 
What fascinates me about that is the time franfi 
months from proposal to bound book. Today, it'i 
miracle if I am only 10 months late. 

The book for Wiley, A Guide to FORTRAN" 
gramming — the black one with the red letters— , 
published in 1961. To my absolute astonishment,! 
still in print and sold a few hundred copies last yea 
It’s not such a bad book in its own way, but it descii 
FORTRAN on the IBM 1620, the Philco 2000, 
few things like that. Good machines in their day, mi 
you, but a little hard to find today. Earlier this wc 
I autographed a copy of the 25th printing. Bi 
imagine why it’s still in print, but there it isfj'l 
written some other books in the meantime that( 
just as soon people bought. 

I guess I am responsible, as some people would 
it, for mutilating the minds of several generatioi 
students. People come up all the time and tel 
got started in this business through your boo' 
always say, “I’m sorry!” 

To try to redress the balance a bit, I’d like ter) 
by saying that it doesn’t always happen thatyj 
After John Mauchly died, his papers were given' to 
University of Pennsylvania. I was ACM presidi 
the time and was involved in ACM’s providing 
of seed money to Penn to start the vast proB 
indexing John’s papers. The first time I calfet 
director of the University of Pennsylvania’s lift 
system, I started to introduce myself, but he stc 
me. “Oh, I know who you are. When I was a gra< 
student I took a fortran course out of your book 
decided to go into library science.” 
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The Emergence of Load-and-Go Systems for FORTRAN 

CHARLES DAVIDSON 


In the 1960s I found myself, along with a rapidly 
powing collection of people, faced with a whole dif- 
ferent set of problems in dealing with FORTRAN. The 
concept of a program that would accept an algorithm 
stated in algebraic terms and translate it into ma- 
chine-executable instructions had been developed, im- 
plemented, and demonstrated. Those of us trying to 
spread the gospel and prepare the next generation 
could see that the world would never be the same. But 
the tools we had available to spread the word were 
designed for a different world. 

Let me paint for you the environment educators 
found themselves facing. In the 1950s the user com- 
munity was still relatively small. Perhaps 100-150 
people at IBM knew something about fortran. In 
the outside world, the Michigan project on the use of 
computers in engineering education had begun to open 
things up. The IBM 650 did as well, but the 650 was 
not a cheap machine — and not particularly easy to 
use, either. 

The education problem was this: we had a mass 
instruction job. In 1960 we started the Engineering 
Computing Laboratory at the University of Wiscon- 
sin. It was dedicated to the proposition that only an 
illiterate engineer of the 1960s would not know how 
to use a computer — and not only how, but also when 
and when not to use a computer. To know those 
things, he had to have had a lot of firsthand experi- 
ence. That meant that if we were going to teach a 
large number of people, we were going to have to run 
* great many jobs— very short jobs, small jobs, and 
| taming-type jobs. For such jobs, the big headache is 
getting them debugged and working right. As soon as 
you get the right answers once, the hell with produc- 
tion— you’re through with it and you start on the next 
other words, you do many short compilations 
- ' *™ very little execution. 

> . T^ e sca * e °f such an operation was a major problem 
, . m itself. The one existing course given by the Numer- 
£ Analysis Department enrolled only 40-50 students 

- J!T Ster ' k an( U e °ur anticipated 700 students, 
mg jn fil ve J°P e d an automated slide-tape lecture series in 
which was used for 10 years by 1000 students a 
for Dau McCracken, we were responsible 

® - w-j*, a large number of people in computing — 
or wrongly. 
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By the same token, undertaking the mission meant 
working with very naive programmers. Not only were 
there a lot of them, but they needed a lot of help. They 
could not all seek out an expert consultant to help 
them get their program working. They had to be able 
to find out on their own where their mistakes were — 
and there were certainly going to be mistakes. Even 
with little jobs, they were going to need a great many 
runs to get their programs working right. 

Furthermore, with all due respect to FORMAT, which 
is tremendously powerful and flexible, there is no 
question that it is the single most complicated state- 
ment in FORTRAN, and the one with which students 
invariably have the most trouble. Beginning students 
and FORMAT statements are a gross mismatch. 

The task of educating this large number of program- 
mers, with limited time and limited resources, required 
a five-prong attack. 

1. An inexpensive computer. 

2. A method of mass instruction. 

3. A processor-machine combination geared to effi- 
cient handling of many short jobs. 

4. A language that made it easy to get started. 

5. A processor that would help users find and correct 
their own mistakes. 

The availability of the IBM 1620 in the early 1960s 
enabled a large number of colleges and universities 
and even some high schools to get into the game. It 
was not, even in those times, a high-speed computer, 
but it was certainly a large cut above the CPC. 

With the 1620, we not only had a computer we could 
use for lots of students, but, thanks to the efforts of 
Jack Palmer and his group at IBM, we had a fortran 
on it. There was no question in our minds that we 
wanted to teach them FORTRAN. We wanted to free 
engineers from the necessity of always going through 
the priesthood in order to approach the most high. 

The 1620, however, was still a small machine, and 
there were a lot of difficulties in crowding a FORTRAN 
into it. I think it was a major achievement to have 
accomplished it at all. Unfortunately, the philosophy 
and goals that guided some of IBM’s difficult choices 
were quite different from ours. It had been decreed 
that every program compiled would be complete and 
self-sufficient. So when you said “fortran” to it, the 
paper tape began punching all the execution-time 
routines that would be needed. Twenty-eight minutes 
later, it got to your first statement! How could we 
hope to service 700 students a semester that way? 
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To Jack’s credit, however, he, along with Laffin and 
Resta, developed an alternate approach to help market 
the 1620, called GOTRAN — a load-and-go FORTRAN. 
This processor did not put out anything that needed 
to be reloaded. As it translated, it compiled directly 
into core. When finished, if there were not too many 
mistakes, it automatically went ahead and executed. 

Unfortunately, in order to fit the translator into 
core and still leave some room for the resulting pro- 
gram, gotran had to be scaled down to a sort of 
pidgin FORTRAN. The assignment statements allowed 
only one operator per statement. A complex expres- 
sion involving N operations required a sequence of N 
separate statements. It had DO-loops, provided you 
were willing to use constants for the parameters. It 
didn’t even try to include FORMAT. Palmer came up 
with an ingenious solution: free format. Let the type 
of variable name in the list determine the type of 
FORMAT conversion to be applied to the data. Then 
provide the standardized format at output time, 
based on the variable type, and let spaces and/or 
commas serve as separators at input. It was an ex- 
tremely effective and valuable solution; it is tragic 
that IBM was never willing to incorporate it into 
subsequent productions. It took 15 years of fighting to 
convince even ASA (now ANSI) that the world wanted 
and needed it. Today we finally have it — list-directed 
format. 

In January 1961 we got our paper-tape 1620 com- 
puter and started teaching using gotran. That first 
semester we taught 700 students to use the thing. 
They were a far cry from FORTRAN programmers, but 
they knew something about how to use the computer 
and what kinds of things you could use it for. 

We weren’t very happy with GOTRAN, however, and 
the appeal of the fuller 1620 FORTRAN still haunted 
us. We decided that with more memory we could have 
the best of both worlds, so we ordered double memory. 
We went from 20,000 to 40,000 digits- — not bytes, 
digits — decimal digits. One of my graduate students, 
Charles McClure, started that spring on the design of 
a load-and-go fortran, to be called forgo, which 
would have the complete capability of the then-avail- 
able 1620 fortran. It allowed complete multioperator 
statements, variable Do-loop parameters, and that 
sort of thing. It fitted into a 40K 1620. It was tested 
that summer, was operational by September 1961, and 
was used for all instructional work that fall. 

In addition to the load-and-go operation, which cut 
28 minutes from the time it took to read in the 
program to usually less than one minute, we gave 
serious consideration to the need for debugging help. 
We wanted more than just syntax checking at compile 
time; that idea wasn’t new, even though a few vendors 
implemented very useful diagnostic messages when 


the compiler did bounce a program. No vendor, -hi 
ever, did anything about helping the user at run tinfi 
we never did feel that ABEND was very construct 
criticism. We implemented in forgo, therefore^ 

1 believe was the first diagnostic fortran compij 
It compiled into its executable program instructs 
to check for: undefined variables, subscripts that) 
ceeded their declared ranges, and similar errorsjtj 
show up only at run time. Furthermore, since wej 
not want this new breed of programmer to ham 
deal with machine-language code, we had the compj 
keep track of the source-language statement each n 
of the executable code came from, so that when sqn 
thing went wrong the student could be given the ini 
helpful error comment we could devise: being refen 
back to the only language the student knew, the FC 
TRAN source-language program. 

We did not have enough room in memory or ont 
punched-card output to assign every line a numbera 
we identified errors in terms of existing Staten*" 
labels plus additional lines, such as: “Statement#! 

2 lines.” 

It worked successfully. We liked the free form 
particularly being able to teach beginning prognn 
mers how to get along without having to learn FORAt 
statements. Since formatted output is often higf 
desirable, the next year we went on to add FOR1U 
but we made it optional. Programmers could useejtl 
free format or the full FORMAT as it existed in t] 
1620 “fortran with format,” which had by., till 
become available. 

That fall we ran about 200 jobs a day through/® 
machine. During those years, we had 1000 student! 
year learning to solve problems with computers.^ 

FORGO was enhanced several times in the nex^u 
years, over two or three generations. One survey do 
ing the mid-1960s reported over 400 college and us 
versity members of the 1620 Users Group using FORC 
in their educational program. Several other compa^ 
and processors also appeared during that period. 50 
entire 1620 Users Group community turned out trrl 
amazingly creative and productive. One list shows|J 
addition to the three IBM FORTRANs for the 162ftjff 
more submitted to the users group, written by so® 
of the other members, including four versions 
FORGO: the University of Toronto FORTRAN, PEHMSPS 
tran, Dick Pratt’s afit fortran from the AiipJwj 
Institute of Technology, and J. A. N. Lee’s- KINQ 
tran, written by the Canadian Drinking and Pfi 
gramming Team. .. . 

John Morrisey of IBM had an interactive,. 
tic QUIKTRAN on the 7040 in 1964. I have nejj 
understood why it didn’t go; I think it was a;||| 
ahead of its time. Purdue University, facing 
problem we did at Wisconsin of trying to develops® 
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S computer education for engineers, produced PUFFT, 
f (],£. Purdue University Fast Fortran Translator, also 
f (orthe 7040 in 1964. It was a full load-and-go fortran 
I !v, but it was only partially diagnostic. DITRAN, a 
Diagnostic Translator stressing complete diagnostics, 
was done at Wisconsin by Merv Muller and Pete 
Moulton for the CDC 1604 in 1966. 

Even though the diagnostic processors were quite 
juccessful, we were never able to get IBM to adopt 
this concept or even to be willing to take over FORGO 
and support it. Although at one time we had six 
different versions of FORGO in the 1620 Users Group 
library, we never felt we had the resources to make 
the major commitment involved in marketing and 
maintaining it. 

The institutionalization of load-and-go was left to 
- the University of Waterloo. When they came out with 
WATFOR, the Waterloo FORTRAN compiler that carried 
all of those features, in 1966, they found an eager 
. market that became worldwide. The Waterloo group 


has been quick to cite as sources for their work both 
forgo at Wisconsin and pufft at Purdue. The world 
owes them a great debt for the marvelous job they did 
over the following decade in providing and supporting 
processors for many phases of the instructional (and 
production debugging) process: WATFOR, WATFIV, 
WATFIV-5, watbol, and other operating systems and 
compilers. . , ,, 

Ditran was adapted from the CDC 1604 to the 
Sperry univac, but was never used outside of Wiscon- 
sin to my knowledge. PUFFT was adapted for time- 
sharing, but seems to survive only at Purdue. FORGO 
went through three generations on the 1620 and two 
more on the Harris machines. FORGO 77 is currently 
alive and thriving as a FORTRAN 77 on the Harris line 
of minicomputers and superminicomputers. 

My major sense of accomplishment is not only that 
we successfully educated 20,000 students in some sig- 
nificant use of computers, but also that we finally got 
free format included in the FORTRAN 77 standard! 


A Dynamic Storage Allocation Language — DYSTAL* 
JAMES M. SAKODA 


I want to talk about nonnumeric applications that 
involve list processing, string processing, simulation, 
formula translation, and so forth. I am going to talk 
about DYSTAL. 

; . - I was in the Psychology Department of the Univer- 

sity of Connecticut when IBM set up a computation 
center at MIT for use by New England colleges and 
universities. I attended the first summer institute 
offered at MIT in 1956, I believe, and struggled 
through the assembly- language programming course. 
At the end of the session, a young man — I believe 
Sheldon Best — got up and announced that IBM was 
; forking on an automatic programming system called 
, FORTRAN. The following year when fortran was 
j&ade available, I attended a short course on it in 
T™? 1011 - As a research associate to the MIT Compu- 
i- tation Center, I began to work on statistical programs 
- in Fortran; since then it has been the only language 
K&'isiM-h I have programmed. I think this is the 
■ ' ”K nenCe man y social scientists and others. 

^ . enc °unter with nonnumerical programming 
the * n ^63 when I attended a summer institute on 
(• U l e , Ip L v for simulation at the Rand Corpora- 
,||£ ^ ■ “ e se ssion was organized by Bert Green. I found 

S' vS?en;£ d £ ress . : , J - M - Sakoda, Department of Sociology, Brown 

£ %.-SysTA r ? v,d M nce ’ RI ° 2912 - 
£. afeipp.'s™ mo AppIication8 of F0HTBAN ” “ NCC 


that IPL V provided dynamic storage allocation using 
linked-word lists. It provided list-processing opera- 
tions such as insertion and deletion, list structures, 
complex structures, and procedures for handling them 
that would not normally be performed in FORTRAN. 
On the other hand, data handling was almost non- 
existent, input/output was difficult, and even a simple 
device like a checkerboard could not be easily repre- 
sented by linked-word lists. Moves on a checkerboard 
were generally done by creating lists of possible lists. 
Furthermore, programs written in IPL V were reputed 
to be slow, and I attributed this to linked-word lists, 
which required sequential access instead of direct ac- 
cess to the middle of list. 

Before the institute was over, I decided to write a 
list-processing language using FORTRAN subroutines 
and functions. I was not aware of Herbert L. Gelern- 
ter’s flpl, which was written in fortran; Joseph 
Weizenbaum’s slip had just been announced, but to 
me it appeared to be ipl v operations written as a 
series of fortran subprograms with a few parameters 
written in machine language.** I decided that in order 
to preserve many of fortran’s essential features, lists 
should consist not of linked words but of a linear 

**H. Gelemter, J. R. Hansen, and C. L. Gerberick, “A Fortran- 
Compiled List Processing Language,” j. ACM 7, 2 (April 1960), 87- 
101; J. Weizenbaum, “Symmetric List Processor,” Comm. ACM 6, 
9 (September 1963), 524-544. 
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string of words. My task was to find ways to provide 
dynamic storage allocation at run time, list-processing 
operations, and creation and operation of arrays con- 
nected into tree structures. I was able to provide all of 
these using procedures written as FORTRAN functions. 
I then proceeded to add string-processing routines, 
sorting operations, and statistical and matrix opera- 
tions, aiming for a general-purpose language. The first 
DYSTAL manual was completed in 1965. After the 1967 
IFIP Working Conference on Symbol Manipulation 
Languages,* I decided to make arrays relocatable using 
a directory to hold the names of arrays and to allow 
arrays to move to a disk file as room in memory was 
depleted. A manual incorporating this improvement 
was put together at Brown in 1970. 

My approach was that of an amateur unaware of 
the niceties of computer-language design, doing what 
appeared necessary to achieve features that FORTRAN 
did not normally provide. Much of this would not even 
be of historical significance since DYSTAL is not widely 
used, but some of it is pertinent to the present effort 
to provide a more general-purpose language via FOR- 
TRAN. The X3J3 fortran committee is discussing 
setting up a core FORTRAN and extensions into differ- 
ent application areas. I believe that the core should be 
relatively flexible to allow a variety of extensions. 

I would like to point out how I was able to make use 
of basic FORTRAN and FORTRAN IV to accomplish un- 
FORTRAN-like operations while integrating numeric 
and nonnumeric procedures. 

Three features were important to my effort to pro- 
vide list-processing and list-structuring operations in 
fortran. The first was dynamic storage allocation. 
The second was the name of an array that was separate 
from its content. In fortran a variable, whether 
subscripted or not, refers to its content or value. To 
create tree structures or to chain arrays, it was nec- 
essary to be able to use names of arrays as pointers. 
This called for a new data type — array name — that 
was different from integers and real variables. The 
third feature was required to provide the flexibility 
inherent in linked-word lists. I found this in the five- 
word head, which I later increased to seven, that I 
attached to each array. 

These features were not independent of one an- 
other. I began with dynamic storage allocation, which 
brought into play the need to keep track of the location 
of an array and its features. Dynamic storage alloca- 
tion also provided the opportunity to attach a set of 
information to each created array. 

•Bobrow, J. G. (ed.), Symbol Manipulation Languages and Tech- 
niques, Amsterdam, North Holland, 1968. 


To implement dynamic storage allocation of line’ 
arrays, a single storage area was created. From itfj 
arrays were allocated at run time. To accomplish ^ 
three variables — LOT, an integer variable; flot, a re 
variable; and GLOT, an extra — were dimensioned^ 
maximum amount and made equivalent to one anoth 
and stored in common. Later a disk file was' addi 
when arrays were made relocatable. The equivalent 
of the three arrays made it possible to cut out ad 
type of array from the same storage area and ever 
store different types of variables in the same 
The equivalence statement therefore played' a 
tral role in providing a flexible dynamic storage 
cation system. The use of common allowed each 
tion to have access to an entire dynamic storage 
without the need to enter LOT and FLOT as argume 
each time. GLOT was placed in common to foofi 
compiler into believing that LOT and FLOT were 
being modified by the FORTRAN function. This 
requirement was encountered in basic FORTRAN w 
working with the IBM 1130 compiler, which said i 
functions cannot change values in COMMON. I w 
deem this to be overprotection of the user, who w 
be better served by the ability to change valued 
COMMON if desired. ■$ f> 

As for array names, it was dynamic storage all' 
tion that permitted and also required a name sep 
from the content of the array. The location whe 
array was stored in COMMON was returned 
integer value that became the name of the arra; 
the head of the array, I put in a counter that 
track of the number of words stored on the arra; 
capacity of the array, the mode of the array, and 6 
pieces of information that were necessary. This 
it possible to have a great deal of automatic pro’ 
ming like the instruction CALL IDUMP (LSTA),;w 
LSTA is the name of the array. This will print ou 
the appropriate format any array in dynamic stor 
The head attached to each array was very use 
Using these three features, I was able to pro 
other un-FORTRAN-like features that included, fo: 
ample, recursion, virtual memory, and string pro! 
ing, although I was handicapped by not having?] 
character data type. The last improvement L 
was to be able to save the entire dynamic storaj 
and to recall it later with another program. 

In conclusion, DYSTAL used linear arrays in p 
linked words and was therefore better able 
advantage of fortran’s efficient processing fea 
It is desirable to keep the basic FORTRAN that is 
planned as flexible as possible; I think this inc 
if possible, keeping EQUIVALENCE and COB 
which they are talking about doing away with,, 
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The Successors to FORTRAN — Why Does FORTRAN Survive? 
SflUCE ROSENBLATT 


1 j, m no t here to talk as a pioneer; I was really a settler 
| f ortran. Settlers are responsible for trying to 
secure the territory laid out by pioneers. There is 
! probably a close relationship between the longevity of 
i /> fORTRAN and the activities that settlers look for — in 

‘ particular, recruitment, colonization, establishing 
good supply lines, and finally trying to figure out ways 
of perpetuating themselves. 

s? • • f In the case of recruitment, there has been a lot of 
discussion about the state of the computer industry at 
f| the time FORTRAN was introduced. All the program - 
s mers thought they were experts. They had to be; the 
! S kinds of programs they were trying to put on machines 

were either too large, too complex, or too tedious to 
do manually. They were trying to take these programs 
and put them on a device that was more expensive (at 
least relatively) than a human being. They had to take 
advantage of all the particular nuances of the equip- 
ment. So they developed a great deal of expertise, at 
least in their own minds. As has been mentioned, 
there was much skepticism that anybody could write 
a general-purpose program that would be able to do 
an equivalent job in efficiency. As a result, several 
kinds of activities were undertaken in order to get 
recruits. 

Standard Oil, where I worked then and still do, had 
a unique way of doing this. Both Mike Roberts (Mike 
had been a member of the IBM FORTRAN support 
team and had recently come to Standard Oil) and I 
were given the same program to solve, he in FORTRAN 
and I in assembly language. While I didn’t feel that I 
was equal to Mike in programming capability, I felt 
comfortable with the job. Mike spent a fairly normal 
week working 8 to 5 each day and went home Friday 
night with the problem solved. I worked extremely 
hard — long overtime and through the weekend — and 
: . . luckily by Monday morning had a solution. I thought 
my solution was better than Mike’s, but the hand- 
writing was on the wall for both me and my cohorts. 
We quickly became FORTRAN advocates. 

Once you solve the recruitment problem, the next 
Problem is supply. In the case of FORTRAN, how do 
>wi keep the program up to date, how do you maintain 
?! how do you support it? Even in those days, 
IBM put support people in the field. Unfortunately, 


i BatacJn^^ ress: Rosenblatt, Standard Oil of California, P.O. 

*1069, San Francisco, CA 94119. 


those people probably didn’t know as much about 
fortran as those of us working with it on a day-to- 
day basis. So it became necessary to establish direct 
contact with the support group. Luckily this wasn’t 
too hard. The user community was fairly small, and 
the support group was fairly visible. They attended 
national meetings and certainly attended all the user- 
group meetings. It was quite realistic to be able to get 
direct support set up in those days. On one of my trips 
east, I discussed with the FORTRAN support group one 
of the things that Standard Oil had found necessary. 
FORTRAN didn’t seem to solve all the problems that 
we wanted to use it for; we were trying to use it not 
only in the scientific and technical area, but also in 
our commercial work. We found that there were areas 
that despite the good coding that fortran produced 
were not as efficient as a hand-coded job. We were 
advocating the insertion of assembly language inside 
a fortran program. Lo and behold, when I left that 
day, in my briefcase in a brown paper wrapper was a 
deck of cards that did indeed have machine language 
inserted in the FORTRAN; historians know this as 
fortran m. Cooler heads prevailed, and fortran hi 
was never released to the public. It probably would 
have set back fortran, which was a pretty machine- 
independent language, many decades. That’s the kind 
of thing that can happen from direct support. 

Given supply and recruitment, the real question is 
how do you set up defenses, and how do you perpetuate 
the system that you have? FORTRAN lends itself very 
nicely to this. First, it is easy to learn and natural to 
use, at least in scientific and technical communities. 
It didn’t take long for colleges to start teaching FOR- 
TRAN to students entering the scientific and engineer- 
ing disciplines. As an example of the ease of use, the 
fortran manual today is about a third of the size of 
those of the other popular programming languages. 
The self-teaching course that IBM gives is planned to 
be taken in 20 hours — about a fourth of the time that 
is estimated to teach or learn COBOL or PL/l. Soon 
after FORTRAN was introduced, it was used as a nota- 
tional method in many scientific publications. 

The general availability of fortran was probably 
one of the most important aspects of its perpetuation. 
There has been a synergistic effect in the case of the 
technical and scientific users. They built up great 
libraries of programs and subroutines that could be 
quickly put on new machines as they were introduced, 
providing they had a fortran compiler. So it was 
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fairly natural to build FORTRAN compilers for all of 
the new machines as they were introduced to the 
scientific and technical industry. There has been a 
great deal of dialogue and discussion on how to build 
compilers, particularly FORTRAN compilers. That in- 
formation has been well disseminated, which has made 
it easy to build FORTRAN compilers on new systems. 

Probably the most important thing about FORTRAN 
has been its adaptability. Subroutines, on-line com- 
puter programming, operating systems, and structured 
programming have all been added to FORTRAN systems 
naturally and easily. FORTRAN has been able to keep 
up with the latest ideas in programming art. Several 
languages have been built on the FORTRAN base: FOR- 
MAC, PROSPRO in the process-control business, PLAGO 
in the construction business, simscript, and Vector 
FORTRAN, just to name a few. 

All of this has helped FORTRAN and its work in the 
scientific community. I think this accounts for its 
continued great usage today. At Standard Oil in our 
exploration, producing, and refining activities, all pri- 
marily technically oriented, fully 80 percent of the 
programming done in those areas is still being done 
in fortran. On the commercial side of the house, 
however, we have not continued to use fortran. 

Over the years we have been able to validate the 
statement that all programmers essentially program 
the same number of statements in a unit of time, 
regardless of the language they have used. Let me give 
one caveat: there is obviously a great difference caused 
by the number of people on a programming effort. We 
found that small programming efforts probably will 



result in about 800 statements a month per progfjj 
mer; for very large programming efforts you get as$ 
as 100 statements per month per person. For u 
that part of it is directly attributable to the efficie: 
and proficiencies of the programming staff, if one c 
reduce the number of statements that one writes i 
program, one can greatly increase production 
have verified this. As we went from assembly la 
to fortran and COBOL, we achieved factors of fi 
and five in our productivity. As we went from » 
tran and COBOL to PL/i, we achieved another 1 
of two or three. More recently, as we’ve gone to i 
house macro PL/i system we call pl/x, we’ve achieve 
another factor of three or four. 

The productivity improvements depend on howw 
one can express a problem in a programming lang 
In many scientific organizations, the whole pr 
can be readily expressed in FORTRAN; therefore, t 
has been no incentive to change. In large gene 
purpose shops, a problem cannot easily be expres! 
in FORTRAN, and most of programming has 
switched to other languages. Even in those 
according to the latest GUIDE survey, approx 
3-4 percent of programming is still done in FOR 

As long as we can continue to build FORTRAN! 
make it adapt to the new programming proce 
and as long as we do not find significant new wa. 
expressing technical and scientific works, we will a! 
tinue to see FORTRAN being used as a progra 
language. It is probably safe to say that 25 years i 
now we will still be able to say there is a large < 
munity using the FORTRAN language. 
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Exhibit Commemorating the 25th Anniversary of FORTRAN 


In October 1981, an IBM committee was formed to 
coordinate certain activities related to the forthcom- 
ing 25th anniversary of FORTRAN, whose commemo- 
ration had been suggested as a 1982 NCC Pioneer Day 
topic as early as 1979 by the History of Computing 
Committee (Harvey Garner, then chairman) of the 
American Federation of Information Processing So- 
cieties (AFIPS). With one exception, the IBM com- 
mittee consisted of employees of the General Products 
Division in San Jose, Calif. — the division currently 
responsible for the majority of fortran program 
products produced by IBM. Members of the committee 
were Daniel N. Leeson, C. J. Lewis, Elliott C. Nohr, 
Florence H. Pessin, and Walter M. Carlson (repre- 
senting IBM’s Corporate Headquarters in Armonk, 
N.Y.). The chairman of the committee was G. R. 
Aguilar. 

The IBM committee had the responsibility of defin- 
ing the nature and extent of IBM’s participation in a 
number of FORTRAN-related NCC events, and to assist 
in carrying out IBM’s responsibilities for a variety of 
tasks needed to make the proposed events successful. 
The purpose of this report is to describe both the IBM 
committee’s role in defining and developing the NCC 
Fortran exhibit — suggested to IBM by HOCC in 
early 1981 — and the exhibit itself. 


© 1984 by the American Federation of Information Processing 
Societies, Inc. Permission to copy without fee all or part of this 
jwterial is granted provided that the copies are not made or distrib- 
uted for direct commercial advantage, the AFIPS copyright notice 
•fid the title of the publication and its date appear, and notice is 
man that the copying is by permission of the American Federation 
Information Processing Societies, Inc. To copy otherwise, or to 
—Publish, requires specific permission. 

™dnor r Address: IBM General Products Division, 5600 Cottle 
J“*d, San Jose, CA 95193. 
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'-Orporation. 
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Responsibility for the exhibit lay in the hands of 
several people. IBM’s exhibit participation at NCC 
was controlled by John J. McMahon of Corporate 
Headquarters. Michael J. Sullivan coordinated the 
layout and design of the FORTRAN exhibit. D. Harvey 
of IBM’s National Accounts Division was in charge of 
liaison with NCC for location and space considera- 
tions. Delma Displays, of Astoria, N.Y., constructed 
the exhibit. 

J. A. N. Lee of Virginia Polytechnic Institute and 
State University, chairman of NCC’s Pioneer Day 
Committee, named William F. Aspray, then of Wil- 
liams College, as the committee’s representative to 
help define the content of the proposed exhibit. He 
and I met for one day in Williamstown, Mass., in 
December 1981 and reviewed a proposal developed by 
the IBM committee and supplemented by earlier sug- 
gestions from Aspray. The nature of the exhibit was 
established as a result of this meeting. Although the 
physical arrangements of the display evolved over the 
next few months, the content never varied substan- 
tially from what Aspray and I agreed to at that meet- 
ing. Consequently, the remaining months in our 
schedule were devoted to acquiring materials and de- 
signing and constructing the exhibit. 

We agreed that the exhibit would consist of a series 
of self-contained subexhibits — each of which would 
illustrate a topic related either to fortran’s devel- 
opment or to fortran’s contribution to and influence 
on computing. A panel honoring the authors of the 
original compiler, a technical panel devoted to their 
, development effort, a panel devoted to public and 
historical events contemporaneous with fortran’s 
early years, a panel devoted exclusively to commer- 
cially printed books on fortran (that is, books from 
private publishing houses instead of from computer 
manufacturers or software developers), and a panel 
devoted to current IBM fortran publications would 
be included. It was also suggested that a running 
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FORTRAN compiler operating on the earliest extant!* 
system obtainable would be interesting; this was soon i 
found to be impractical, and we substituted a non- 
operating IBM 704 central processing unit. Ultimate- * 
ly, the exhibit consisted of the following seven items. i‘| 

1. A nonoperating IBM 704 was the centerpiece of 
the entire display, with the other panels arranged 
around it iFigure 1). We chose the 704 because the ■ V 
first fortran compiler was written for this computeri?* 
We ultimately rejected the earliest extant running'll 
FORTRAN compiler we could locate (which turned out i 
to be on an IBM 1620 in Kingston, N.Y.) because it X' 
was historically unjustified. The presence of the IBM X- 
704 created more comment than any other portion of -’i 
the exhibit. 

2. While the subexhibits could be visited in any 

order, the panel entitled “Pioneers of Fortran” was 
placed so that it was both physically and logically the A 
first stop in any visit to the display (Figure 2). It 
contained individual pictures of the original develop- || 
ment team taken about 1954-1957, brief biographical |S 
sketches of each pioneer, and each pioneer’s technical ill 
contribution to the first FORTRAN compiler. There was 
also a large photo of the attendees of an early (possibly ‘P 
the first) fortran class held for IBM Applied Science 
Representatives, a precursor of today’s System Engi- 
neering organization. •••£# 


Figure 1. An IBM 704 central processing unit was the 
centerpiece of the fortran exhibit. 
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3. The next panel was entitled “Early Manuals and 
Brochures" (Figure 3). This section of the exhibit 
included a sampling of some of the earliest extant 
documentation associated with the original 704 for- 
tran compiler as well as a smattering of memorabilia, 
such as the large, hand-drawn, original flowchart of 
the index-register allocation scheme of the original 
compiler (by Sheldon Best), the actual output of what 
is believed to be the first successfully run complete 
FORTRAN program (the calculation of a Laplace trans- 
form), some of Roy Nutt’s expense accounts for trips 
between New York City and Hartford (the location of 
United Aircraft Corporation, Nutt’s employer at the 
time), a 1956 run of the compiler’s first handling of 
subscripted arrays, and contemporary pictures of the 
various pioneers. Original copies of the earliest public 
fortran manuals (the 1956 Programmer’s Reference 
Manual and the 1957 Programmer’s Primer) and a 
French version of the language manual (which docu- 


ments the existence of a nationalized implementation 
of FORTRAN, one that invoked function only in French; 
for example, one was obliged to write “faire” instead 
of “do”) were also included, as were later manuals 
describing implementations of FORTRAN done by IBM 
and other computer manufacturers. No effort was 
made to be exhaustive. After the FORTRAN compiler 
for the IBM 704 was made available, implementations 
on other equipment, both IBM and non-IBM, became 
commonplace; consequently, the selection of material 
showing other IBM FORTRAN implementations as well 
as non-IBM ones was arbitrary. (Facsimile copies of 
the two earliest public 704 FORTRAN manuals were 
given as mementos to attendees of the banquet that 
concluded the 1982 NCC Pioneer Day sessions.) 

Materials for this panel were located in a number 
of private collections, two of which are unusually 
noteworthy. Roy Nutt and Harlan Herrick have both 
made a special effort to retain material from their 



Figure 4. “Mood of the Era.” 
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Figure 5. “Books and Artifacts. 


Figure 7. Fortran film. 


early days in computing. Nutt possessed a microfilm 
of (allegedly) every document in the FORTRAN devel- 
opment offices at the time the product was released. 
He generously donated a copy to the IBM historical 
archives. Herrick’s collection of memorabilia was also 
extensive. For example, he owned the only known 
copy of IBM’s first FORTRAN film, made in Pough- 
keepsie about 1958, that showed how FORTRAN could 
be used to program a solution to “The Indian Problem" 
la calculation demonstrating the effect of compound 
interest on the $24 said to have been paid for Man- 
hattan Island). 

4. The panel entitled “Mood of the Era” (Figure 4) 
was originally thought of as a collection of newspaper 
headlines from the week of April 15, 1957 (the ap- 
proximate date of the first documented shipment of 
the fortran compiler from IBM to a user, Westing- 
house-Bettis). We soon realized that the mood of this 
era could not be captured by the headlines of such a 


6. The panel “Fortran Today” (Figure 6) was 
originally intended to be a display of every currently 
active IBM manual dealing with fortran. The sheer 
number of these documents soon made this impracti- 
cal, so a representative sample of approximately 150 
such manuals was arbitrarily chosen. 

7. In a small, 80-seat theater immediately adjacent 
to the exhibit, two television monitors continuously 
showed a specially made film on FORTRAN (Figure 7). 
The following section of this article tells about the 
origin and content of the film. 

A few weeks after NCC ’82, the exhibit was relocated 
for a week (July 12-16) to the Santa Teresa Labora- 
tory, San Jose, the site of most of IBM’s current 
fortran activity. The exhibit received its final public 
showing at the SHARE 59 meeting held in New Or- 
leans on August 22-27. (See the Meetings in Retro- 
spect department of this issue, pages 65-69, for more 
information about these events.) On December 6, 
1982, I dismantled the “Early Manuals and Bro- 
chures” panel and sent the material from this section 
back to the owners. The remainder of the exhibit was 
donated to the Special Collections Division of the 
Carol E. Newman Library of Virginia Polytechnic 
Institute and State University. 


new IBM language development; if any such news 
clipping exists, we were unable to find it. The intro- 
duction of FORTRAN was, from the media’s viewpoint, 
a nonevent. The long-term impact of FORTRAN was 
not suspected even within the computing community, 
so it is not surprising that no press notice was given 
of its birth. 

5. The panel entitled “Books and Artifacts” had two 
logical sections (Figure 5). The first section mounted 
approximately 50 published books on FORTRAN. Our 
original intention was to span the 25-year period with 
every published FORTRAN book. The response from 
publishers to Aspray's request for sample copies was 
so overwhelming and generous, however, that it 
quickly became necessary to scale down our original 
objective. The second logical section of this panel 
contained a variety of artifacts that — while not im- 
portant to the history of FORTRAN — were a part of the 
last quarter century's overall FORTRAN milieu. These 
artifacts included a T-shirt emblazoned with a tribute 
to fortran, microfiche of an arbitrarily selected FOR- 
TRAN compiler’s source code, and an Infograph, or 
pop-up telephone pad look-alike, with indexes to the 
correct grammar and syntax of any given FORTRAN 
statement (see Oswald 1964 in the Bibliography). 


Motion Picture Created for the FORTRAN Exhibit 


cumstances surrounding fortran’s development ef- 
fort: its origin, its labors, its difficulties, its successes. 
The assumption was that capturing the original de- 
velopment team’s recollections of the 1954-1957 era 
would be historically worthy. The proposed approach 
met some resistance because of a previous experience 


m on fortran was part of the IBM exhibit 
’ring the 25th anniversary of the delivery of the 
implementation of the language. The film was 
Proposed in December 1981 by the IBM General 
ucts Division committee. They suggested that the 
nal authors of fortran discuss on film the cir- 


Figure 6. “Fortran Today. 
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with such a film technique; some individuals who for 
one reason or another were not included in that film 
felt their participation had been overlooked. 

The situation with FORTRAN was quite different; 
only nine IBM employees and two non-IBM employ- 
ees were involved in the first fortran development 
effort. We knew who they were, where they were, and 
the precise nature of their contributions. There was 
little likelihood that anyone outside of this group 
would claim an unrecognized contribution of one type 
or another. 

Our proposal was accepted, and the New York firm 
Bright Star Films (now David Grubin Productions) 
was selected to do the scripting and filming. The 
producer, W. J. Teitler, assumed responsibility for the 
artistic content of the film, while C. E. Pankenier and 
F. T. Franco, -Jr., both of IBM’s Corporate Headquar- 
ters. retained overall control of the project. -J. G. 
Damon, also of Corporate Headquarters, later as- 
sumed control of the project when Pankenier and 
Franco assumed new positions. Our committee became 
responsible for the technical content of the film and 
assumed the role of IBM coordinator. 

Franco, Teitler, and I met in San -Jose in early 1982 
to plot strategy for the development of the film. I 
proposed that our assistance to Teitler would be most 
valuable if it were done in four phases. 

1. The first order of business was to acquaint Teitler 
with fortran fundamentals so that he could make 
artistic decisions based on a reasonably informed un- 
derstanding of what FORTRAN was and what it did. 

2. Next, we established a series of interviews be- 
tween Teitler and four individuals who were not part 
of the original fortran development team, but who 
could provide insight into the computing milieu of 
1948-1957. Meetings were set up with A. L. Harmon, 
then IBM Western Region manager of Applied Sci- 
ence, now retired; Frank S. Beckman, then IBM man- 
ager of 704-709 programming, now chairman of the 
Department of Computer .Sciences, Brooklyn College 
of the City University of New York; Florence H. 
Pessin, then a programmer with IBM, now IBM Man- 
ager of System Information, Santa Teresa Laboratory; 
and William P. Heising, then technical assistant to 
the IBM manager of Applied Programming, now an 
IBM manager of a fortran project in Kingston, N.Y. 
To make sure that this strategy was productive and 
valuable to Teitler, I monitored these meetings. 

3. The members of the original development team 
were contacted to establish initial interviews. We also 
introduced Teitler to Cuthbert C. Hurd, then IBM’s 
manager of Applied Science and John W. Backus’s 
manager, now retired. All of the original team agreed 
to be interviewed, except Grace E. Mitchell, now re- 


OR, 

tired from IBM, who expressed the wish that she not 
participate in the proposed events. I was present at 
many of these meetings to provide technical insight 
to T eitler; that is, both during and after the interviews: : - 
the technical significance of the responses to Teitler’s ■ 
questions were discussed in great detail. 

4. The committee members were available to Teitler'-" 
during the editing process to provide technical support 5 
if needed. 

In early 1982, after completion of the first two 
phases of the proposed strategy, we felt that Teitler " 
had enough background, both technical and historicaE® 
to enable him to ask the development team’s members. 7 
penetrating questions. I accompanied him on the first' 
several interviews and assisted in questioning the’. ; 
interviewees — partly because there were a number of ; 
questions I personally wanted answered about the it 
development of fortran and partly to make certain 
that Teitler was exposed to ideas the committee felt -5 
to be of seminal importance. 

These visits, each of which took several hours, were • 
tape-recorded, but no filming was done. When all of 
the interviews were finished, Teitler prepared a tran- 
script of the sessions so that he could select areas of . 
particular interest for filming. The choice of which m 
areas of the discussion were valuable generally be- . 
longed to Teitler, but occasionally one of the commit- ® 
tee members would point out how a particular com-jfl 
ment from one of the interviewees illuminated either -i 
the creative process or the business and technical j|; 
rationale behind it. Teitler was receptive to these > 
suggestions, and we appreciated the fact that we were (< 
able to provide added value to an artistic project by, 
virtue of our technical and historical perspective. 

The filming itself, carried out in the late winter and 
early spring of 1982, was both anticlimatic and far | 
more laborious than anything that had gone before. 
Often several hours were necessary to prepare for the I 
filming. This included special lights, filters, locations, | 
and all the accoutrements of filmmaking. For example,," 
eight film technicians and three IBM employees were. 
present at John Backus’s home in San Francisco. The" 
morning was spent preparing for the filming, which 
occupied the entire afternoon and produced almost 
three hours of film. Cuthbert Hurd was filmed at his 
home in Portola Valley, Calif.; Richard Goldberg at the 
boat basin in Central Park, New York City; Sheldot 
Best at his home in Tenafly, N.J.; Lois Mitchell Haibt 
Robert Nelson, and David Sayre at IBM’s Thomas 
Watson Research Center in Yorktown Heights, N.Y.; 
Irving Ziller at an IBM location in White Plains, N.Yi 
Peter Sheridan at his home in Pleasantville, N.Y 4 
Roy Nutt in his automobile in Los Angeles; Harlan 
Herrick at an IBM location in Manhattan. 
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Each filmed interview had Teitler off-camera asking 
a series of prepared questions. While the questions 
were derived from the transcript of the earlier inter- 
views, Teitler was flexible enough to pursue a new line 
spontaneously if it appeared to be fruitful. The same 
question would often be put to the interviewee several 
times if the answer was not to anyone’s liking, or some 
technical problem occurred with the filming, or the 
-pirir of the earlier interview session was difficult to 
recapture. Also, in the back of Teitler’s mind was the 
desire to have the same question answered by several 
people and then to piece together multiple perspec- 
tives of the same event. 

After the total film shot had been edited from 
approximately 30 hours to the first proposed version 
of 22 minutes, two members of the committee had the 
opportunity to see it and provide input to Teitler. The 
film was ultimately shortened to 12 l A minutes, and 
this version was used at all subsequent events. The 
film was first shown publicly at the IBM Corporate 
Recognition Program held at the Waldorf Astoria 
Hotei, New York City, in May 1982. The film then 
became part of the XCC Pioneer Day exhibit and was 
later used for a variety of commemorative events 
associated with FORTRAN. (Copies are available from 
Modern Talking Picture Service in Atlanta.) Because 
of the foresight of both Teitler and Damon, a copy 
was made of the complete footage shot; it now resides 
in the IBM archives in Armonk. On November 5, 
1982, the film won a bronze medal in the “Industrial 
Production. Corporate Image” category of the 25th 
Annual New York International Film and Television 
Festival. 

The following is a complete transcript of the final 
version of the film as it was shown to the public. 

:Lead): In 1953 an IBM research project led by John Backus 
began to develop the world’s first practical high-level 
programming language for a computer. Its aim was to 
make computers more accessible, and to create a system 
that would make programming easier and more economi- 
cal. This is the story of the creative process at work told 
hv the people who made it possible. They developed a 
language. They named it fortran. 

John Backus: It was very informal so that, for example, 
when I thought that we should try to make this FORTRAN 
system, I simply wrote a letter to my boss at the time, 
Cuthbert Hurd, and suggested that we do that, and he 
said “Fine. Do it!” 

Cuthbert Hurd: In August of 1952, the engineering model of 
the Defense Calculator, later named the 701, was running. 
And I think we had six orders. We invited a representative 
irom each of the companies who had ordered the machine 
to come to Poughkeepsie for a week, and we each got a 
shot at this computer. You write this program and, BAM!, 
>ou get the result. And we all sat there and said, “How in 
e world are we going to keep these machines busy? 
ay re so tremendously fast. How can we do that?” 


Backus: The fortran team, of course, was put together 
gradually as the problem that we had to deal with got 
larger and larger. It began with Irv Ziller and myself. 

Irving Ziller: Our primary objective or focus was to permit 
people to concentrate on the essence of their problems 
and eliminate preoccupation with the mechanics of the 
computer per se. 

Backus: Very shortly after that Harlan Herrick joined us. 
Harlan Herrick: I said, “John . . . Backus .... we can’t 
simulate a human programmer using this language— put- 
ting a problem and getting an object code from the 704— 
that would even approach the efficiency of a human 
programmer. Like me, for example. I’m a great program- 
mer you know.” 

Backus: And then we hired Bob Nelson. 

Robert Nelson: I came to work for John Backus. The first 
day that the FORTRAN group met, there were four of us on 
that day. And I actually was hired as a technical typist. 
Ziller: . . . and eventually became one of our best technical 
people. 

Herrick: Then we gradually acquired some people from out- 
side of IBM. Sheldon Best from MIT. 

Sheldon Best: Almost everyone was already there when I 
came. There was John Backus, Harlan Herrick, Irv Ziller. 
Bob Nelson, I think, came about the same time I did or 
maybe a little afterwards. I can’t remember exactly. 
Herrick: And Roy Nutt from United Aircraft who gave a lot 
of his time to us. 

Roy Nutt: We responded right away and shortly afterwards 
I took a trip down to talk to him [Backus]. 

Backus: And shortly after that Peter Sheridan joined us. 
Peter Sheridan: I was tickled pink when John decided to 
take me aboard. 

Backus: David Sayre joined about that time, too. 

David Sayre: I joined IBM in 1955, and I joined as a 
mathematician. 

Herrick: Lois Haibt came. 

Lois Haibt: It was just after I graduated from college as a 
math major, but knew nothing about computers except 
that they existed. 

Backus: Dick Goldberg, a mathematician, who joined us 
about midway. 

Richard Goldberg: Well, it was very exciting. It was com- 
pletely outside of my experience. I had been in academic 
life before that, and I never had done that kind of crash 
thing. But there was a— you know, like all things that are 
out of the ordinary — there was a lot of excitement. 
Herrick: These were very unusual people. Some of them were 
extremely unusual. It was almost a matter of fate that 
they came to join us because they had certain abilities 
and, without them, we probably would never have been 
able to do what we did. 

Ziller: And in the background was the skepticism, the en- 
trenchment of many of the people who did programming 
in this way at that time; what was called “hand-to-hand 
combat” with the machine. 

Sheridan: So we had to discover all the technology that we 
needed ourselves. 

Herrick: We’d come to work; there was an elevator that 
worked very slowly, and as soon as Irv and I or Peter and 
I got on the elevator, the elevator man, Lou, would look 
to us and say “Oh, there they are. Bring the men in the 
white coats.” We were sort of irregular IBMers. 

Nelson: We lived in a room where we all had desks, no 
dividers. 
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Ziller: And the desks were butted up against one another. 

Backus: It was a quaint little place. Very pleasant. 

Sayre: We were all in each other’s pockets. 

Sheridan: We worked as a kind of small family. 

Ziller: We were in completely uncharted waters: we were 
trying to do something that basically nobody had ever 
tried to do before, and nobody had ever succeeded in 
doing. 

Haibt: None of this theory existed. Nothing was known 
about parsing; it was all invented at the time. It wasn’t a 
case of choosing between this method and that method, 
or this theory and that theory. There were no theories. 

Best: We were engaging in something that was not an 
everyday activity, something that was not a humdrum 
thing. 

Nelson: It was an act of faith. There were no benchmarks to 
compare the work to. There was only the group of us 
working together and seeing what each other was doing 
and having faith in ourselves. 

Backus: Occasionally people did ask us how long it would 
take: “When are you guys gonna be done?” We would 
always say, “Six months. Come back in six months.” We 
honestly felt all the time that we'd be done six months 
from now, but it turned out to be three years. 

Nutt: .John was really more of a leader of that effort than 
he cares to admit. 

Backus: We spent a lot of time talking together and perhaps 
that helped to motivate us all. 

Sayre: In some way that I don’t know, he [Backus] managed 
to keep a little pool of silence that the group could work 
in for long enough to carry out what they needed to do. 

Ziller: What, kept us going. I think, was the challenge of the 
problems, the feeling that we were going to succeed, and 
the teeling that what we would succeed in doing was more 
than completing a project, but doing something that would 
fundamentally advance the state of the art. 

Sayre: Little by little it didn’t make mistakes. Then when it 
stopped making mistakes, or almost stopped making mis- 
takes, we could finally issue fortran. 

Herrick: “Fortran.” It sounds like something spelled back- 
wards. 

Backus: We would continuously invent very trite names for 
the system. I would come in with today’s name and try it 
out on my friends, and they would all say, “Oh God, 
Backus! No, not that." 

Herrick: Then one day he came in and said, “I’ve got it. 
‘Formula Translation' . . . ‘fortran,'" and I went “Yech!” 

Nelson: But it was the only thing we had, so FORTRAN it 
became. 

Hurd: The people I have known who have made great 
innovations — von Neumann, Nobel Prize winners I have 
known, others, John Backus — they have to be able to 
think tops-down and bottoms-up. There are very few 
people like that. 

Ziller: Perhaps the most important characteristic for scien- 
tific innovation is a freedom of association, the ability to 


interrelate what perhaps for most minds would appear tr» 
be totally disparate and unrelated— a leap of connectivity? ^ 
a leap of logic. 

Backus: ... to ask a new question that hasn’t been asked 
before, that brings out an aspect of the subject that 
unnoticed. 

Herrick : ... a lack of inhibition— an ability to throw out the 
feelings that you can’t do it and let yourself really become 
free inside. " 

Goldberg: People are very different. I myself am very sW^ : 
and like to go very deeply and in great detail into things/ 

So that takes persistence and patience. 

Backus: ... and willingness to fail all the time. And you 
constantly try, you have to generate many ideas and then 
work very hard only to discover that they don’t work. And ? ' 
you keep doing that over and over again until finally you ' 
find one that does work. 

Nelson: If you really are working in a new area, I think fe 
helps if you are something of a science fiction writer '' 
Because you have to construct scenarios about how to get 
from here to there, where “there” is someplace no one has 
ever been before. 

Backus: We just thought of it as something that would make ? 
programming the 704 very much less expensive and very • > 
much easier and more accessible. But we didn’t have the 
slightest idea that it was going to cause such a stir as it 
finally did. » 

Haibt: I think it was a very well thought out thing. ItV ''' 
simple and it’s elegant. 

Herrick: And I think it’s quite natural. It’s a language that 
is very easy to learn. 

Best: But it’s also adapted. I mean it’s changed. 

Goldberg: It s still a very good big language for programming ; 
scientific programs in. The notation is really quite close 
to what mathematicians and scientists use. And, further- : ? 
more, it produces good programs. 

Herrick : I certainly could never have foreseen how it would/.:: 
have affected my life. But it has affected my life now, very 
deeply. 

Nutt: It makes one very thankful and proud. Of course, we*d 
all be crazy if we weren't proud of it. 

Haibt: It s not everybody that starts out their working life . • 
with such an absolutely marvelous project. 

Backus: The really remarkable achievement that my friends 
made in producing the compiler is not well understood by __ . 
the computer world in general. They set out to produce a 
compiler that would produce the most optimized programs .L 
possible. And they did this in such a superlative way by a 
remarkable group effort that this compiler produced the^K 
most optimized programs for the next 20 years. And when fjP- 
you compare that with other technological efforts, what >y 
other computer has ever survived for more than five years? 
What program stands as the best program for more than / • 
two or three years? One can hardly think of any techno- 
logical effort that stands as the best work in its field for 
more than a few years. And this one stood for 20. 
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An Annotated Bibliography of 

fortran 

COMPILED BY J. A. N. LEE 


Introduction 

The papers listed in this chronological bibliography 
have been selected on the basis of their relationship 
to the language FORTRAN, its implementations, its 
derivatives, and its definition. Only in exceptional 
cases have references been included to the use of 
FORTRAN in specialized applications. Papers have 
been included where the application is in the devel- 
opment of a secondary language, however, or where 
the modification of FORTRAN is capable of supporting 
some application other than “scientific programming.” 
For historical completeness, a few references have 
been included to pre-FORTRAN systems that were ref- 
erenced in some of the early FORTRAN publications. 

We have kept punctuation to a minimum in the 
titles in the bibliography; for instance, we haven’t 
used italics or quotation marks for book or article 
titles. We give the form of the name of the language 
used by the author (FORTRAN or Fortran) in the 
title, but we give our usual form of small capitals 
1 fortran) in the annotations. A dagger (t) preceding 
an author’s name indicates that the author is not 
listed on the document itself, but the best recollections 
of the participant(s) point to that author. 
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1954 

Laning, J.H., and N. Zierler, A Program for Translation of 
Mathematical Equations for Whirlwind I. Eng. Memo. 
E-364, MIT Instrumentation Lab., Cambridge, January 
1954, 25 pp. 

This surprisingly modest report outlines the language to be 
implemented for the Whirlwind to “solve” mathematical problems. 
The major emphasis is on the representation of equations and the 
use of special notations for subscripting. The flexowriter used as 
the input device possessed superscripting capabilities as the upper- 
case representations of the digits; subscripting was to be represented 
by the notation of a vertical bar (|) followed by a superscript. Only 
vectors are mentioned as structures; flow of control includes (in 
modern terms) unconditional GO TO, a branch on negative result, 
and two commands that enable the programmer to execute a single 
statement remotely (that is, a one-statement procedure call). 

Backus, J.W. The IBM 701 Speedcoding System. J. ACM, 
1, 1, January 1954, 4-6. 

John Backus must hold some kind of record for papers that 
appear in Vol. 1, No. 1 of journals— though this may be his first! 
The following is from the summary: “Speedcoding is a floating point 
three-address system which greatly simplifies programming, and 
checking out a program. Speedcoding provides convenient input- 
output operations, built-in checking, easy loading and printing. 
Therefore, Speedcoding reduces programming and testing expenses 
considerably. These expenses are often a large part of the cost of 
operating a computing installation. Thus Speedcoding is economical 
as well as convenient to use.” 

Backus, J.W., and H. Herrick, IBM 701 Speedcoding and 
Other Automatic Programming Systems. Proc. Symp. on 
Automatic Programming for Digital Computers, Washing- 
ton, Office of Naval Research, May 1954, pp. 106-113. 
t Backus, J.W., H. Herrick, and I. Ziller, Preliminary Re- 
port: Specifications for the IBM Mathematical FORmula 
TRANslating System, FORTRAN. Programming Research 
Group, Applied Science Division, IBM Corp., November 10, 
1954, 29 pp. (mimeograph). 

This is the first formal proposal for the language fortran. It 
lists the elements of the language that are proposed to be included 
in the eventual implementation, together with some suggestions for 
future extensions. It is interesting to match this proposal with the 
Programmer’s Reference Manual (1957) and to note that many of 
the ideas of later fortrans as well as ALGOL appear to have been 
given birth in this document. 


Annals of the History of Computing, Volume 6, Number 1 , January 1 984 • 49 


J. A. N. Lee • Pioneer Day 


to take place. The reverse sides of the cards were 

imprinted with well-known sayings about fortran 

not all complimentary. The Pioneer Dav chairman 
believed that the fortran concept was so'strong that 
it was in fact a compliment to be the subject of “digs” 
trom such eminent computer scientists as Edsger W. 
Dijkstra. These cards came in sets of eight (including 
one blank reverse side). They were passed out every- 
where at NCC and were sought avidly by a number of 
fortran enthusiasts. 

Press Conference 

With the assistance of Nadine Fletcher of IBM San 
■Jose, a press conference was arranged on the morning 
of Pioneer Day. All nine original pioneers in attend- 
ance at NCC were present, led by -John Backus; the 
session was chaired bv JAN Lee. 


I O 





John Backus with original 
fortran flow diagrams. 


The concept of an exhibit for the fortran 25th 
anniversary was based on the success of the exhibit at 
the UNIVAC I anniversary in 1981. IBM agreed to 
produce an exhibit, and exhibit designers coordinated 
with the Pioneer Day committee on the conceptual 
design and identification of artifacts. The resulting 
exhibit is described by Daniel N. Leeson in this issue. 
After NCC the exhibit was shown at the IBM Pro- 
gramming Center at Santa Teresa. California, and at 
the 1982 SHARE meeting in New Orleans. 


IBM offered to produce a film commemorating the 
25th anniversary of fortran to be shown repetitively 
at the exhibit. The film went through several versions 
before the one finally used at NCC was selected: a 12- 
mmute look at the pioneers and their work (the length 


• 

of the film was based on "sitting ability" of the n n t« ' 
tial viewers). perhap S a longer version will be nSi 
available by IBM for use in universities and profes- 
sional societies. The film is also described by lZ!# 
in this issue. eso S» 

Archive 


The guidelines for Pioneer Day established by HOPplf 
specify that one of the potential objectives is to estab- 
lish an archive for materials related to the topic Th» 
assumption was made at that time that such an arf 
chive would be established at the Charles Babbage’ ' 

^ 3 number of considerations led 
the 19b- Pioneer Day committee to decide to establish 
a separate archive. The Pioneer Day chairman has- 
been active in the establishment of other archival 
collections at Virginia Polytechnic Institute and State 
University. He proposed to CBI and HOCC that the’ 
fortran archive be established at Virginia Tech The 
proposal was approved, and the special collections 
division of the Carol M. Newman Library at Virginia’ 
lech is looking forward to working on the archive 1 

mv, S v-v hree elements of th « collection will be the ■ 
IBM exhibit, the files of the Pioneer Day organizing 
committee and materials collected during its work 
and the FORTRAN files of the American National Stan- * ■ . 
dards Committee for the years 1962-1982. 

Banquet 

The responsibilities of the Pioneer Day committee 
have expanded through the years to include a number jl 
of ancillary activities surrounding the NCC sessions. • 
The major event is the Pioneer Day banquet, which 
has been as simple as a pay-as-you-go reception (at 
t e SHARE session in 1980) and as extravagant as a - 
black-tie dinner (at the univac session in 1981). In % 
accordance with the wishes of John Backus, the pro- / 
gram at the fortran banquet was kept simple and jfi 
dignified while at the same time givingthe opportunity ^ 
for a little levity. Bernard A. Galler, editor-in-chief oftf® 
the Annals, a member of HOCC, and a long-time 
fortran user, was master-of-ceremonies/toastmaster 
and wove tales through the anecdotes told by several 
pioneers. At the end of the evening, the film IBM had A; 
produced for the exhibit was screened. A commemo- % 
rative plaque (shown in the front of this issue of the 
Annals), was presented to Ralph Gomery, vice-presi- 
dent and director of research for IBM, by Daniel D. 
McCracken, chairman of the AFIPS History of Com- |§ 
puting Committee, and reproductions of the original -■ j 
two fortran manuals were given to everyone at the : 
banquet. 
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JOHN BACKUS, CHAIR 


Early Computers and Computing Institutions 
john c. McPherson 


To open the subject of the history of FORTRAN, I want 
to pose a question: why was FORTRAN created where 
and when it was? This gives me a chance to go back 
into some of the early history of computing. For a 
quarter of a century before 1955, punched-card ma- 
chines were automating number handling and record 
keeping in the office. IBM was selling not only its 
machines, but also its assistance in installing and 
maintaining machines. Education of its sales repre- 
sentatives, customers, and prospective customers was 
a major activity of the company. The company sought 
the aid of university professors in setting up its school; 
Thomas ■]. Watson, Sr., was anxious to find ways of 
helping the education field, although this was clearly 
not part of our commercial business. 

During the 1930s and 1940s, IBM gave a set of 
machines to Benjamin D. Wood, of the Statistical 
Bureau at Columbia University, for research work. 
" e l ater set up the Astronomical Computing Bureau 
at Columbia, in association with the American Astro- 
nomical Society and Columbia University. A few years 
tater. IBM undertook the development of the first 
really large-scale computer, for Harvard University — 
-he Harvard Mark I (the Automatic Sequence Con- 
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trolled Calculator). During that period, two IBMers 
(Eckert was a future IBMer) wrote books on the use 
of punched cards in research and the sciences.* These 
books really inaugurated the use of punched cards as 
scientific adjuncts. 

During the course of World War II, Eckert went to 
the Naval Observatory to set up and rapidly produce 
the American Air Almanac for flyers. (Data produced 
by the German Nautical Almanac Office had been 
used earlier.) As a result of this and the war, major 
impetus was given to automatic calculations. Some 30 
organizations, including Los Alamos Scientific Labo- 
ratory, Aberdeen Proving Ground, Naval Observatory, 
Grumman Aircraft, Curtiss-Wright, and most of the 
airplane companies, were making effective use of 
punched-card machines for automatic calculation by 
the end of the war. 

Right after the war in 1946, we were able to add to 
the punched-card machines the 603 electronic multi- 
plier that had been developed by Byron Phelps at IBM 
Endicott in the early 1940s. After announcing that 
first electronic calculator and immediately putting it 
on the market, we brought out the 604, which was a 
programmed electronic calculator that went through 
some 60 program steps (of calculation) before it had 
to put information back on punched cards as its 
backup store. A year after the 604 was out, people on 
the West Coast urged us to combine the 604 with the 
tabulator as a storage unit to make the Card Pro- 
grammed Calculator (CPC). During the next 10 years, 
many, many people used this tool to learn how to use 


Author’s Address: J. C. McPherson, P.O. Box 333, Short Hills, NJ 
07078. 

* Wallace J. Eckert, Punched Card Methods in Scientific Computa- 
tion, T. J. Watson Astronomical Computing Bureau, Columbia 
University, 1940; G. W. Baehne (ed.), Practical Applications of the 
Punched Card Method in Colleges and Universities, Columbia Uni- 
versity Press, 1935. 
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punched-card methods for automatic calculation as 
distinct from hand calculation. 

To point out how crude things were just before and 
during the war, there was a mathematical tables proj- 
ect in New York City under Arnold Lowan. Several 
hundred people worked with spread sheets 40 inches 
long and 20 inches high. Each step of the calculation 
was done by a person who did no more than add or 
perhaps multiply by one digit. This project was meant 
to produce a whole set of coordinates for the revision 
of war maps for the United States’ use in Europe and 
other major mapping problems. 

The use of the CPC during the war and a few years 
after it taught a great many people who had never 
heard of punched cards or computing by machine how 
to do it. For that purpose, a series of education re- 
search forums that had been suspended during the 
war were resumed in 1946. They soon became semi- 
nars in scientific computation, where customers ex- 
changed their experience with punched-card solutions 
to various problems. The Watson Scientific Comput- 
ing Laboratory at Columbia was another major activ- 
ity of the company to spur interest in computers and 
the use of computers. In the course of the next few 
years, some 1500 people from all over the world came 
to the lab to spend three or four weeks using the 
various pre-electronic computers then available. As a 
result, a large body of user knowledge accumulated 
within IBM. 



At the same time, having finished the Harvard Mart i' 
I-a machine developed and built of standard:: 
punched-card parts, some 24 tabulators rolled into one 
and run from one big driveshaft— we designed an ; 
electronic follow-on to that machine for our own uS : 
the Selective Sequence Electronic Calculator (ssm 
It was used for a great many problems in scientific® 
calculation by research people from all over the court & 
try. The ssec was the biggest if not the fastest ma 
chine available at the time, and it tackled extremely® 
large problems. fg; 

A few years later we began to look at programming 
problems from John Backus’s standpoint. By that! 


time, there were probably 50 to 100 people in IBM 
who knew something about doing scientific calcula 
tions. They had to work from essentially a zero base 
They challenged the generally held belief that com-'* 
puters could not produce efficient programs from or- ’ 
dinarv mathematical equations. They succeeded and 
so we are here today. (In many ways the present U 
massive efforts to program microcomputers and per- 't 
sonal computers raise the same challenges and call for 
new breakthroughs of comparable significance.) f > ’ 
With the growing interest in scientific computing v 
an Applied Science Department was formed under 
Cuthbert C. Hurd to assist our field people in working 
with scientists, engineers, customers, and prospective S’ 
customers on applications for the 604 and the CPC and ' 
appraising the needs for high-speed computing. 


Computing Prior to FORTRAN* 

ROBERT W. BEMER 


In order to talk about how it was before fortran, I’m 
going to cast it in modern terms, like structured 
programming and performance analysis. When I went 
back to analyze the papers given at the Western and 
Eastern Joint Computer Conferences, I was surprised 
to find that software was presented so late. In fact, it 
wasn t until the fourth Joint Computer Conference in 
1954 that there was even one software paper; in 1955 
there were still only five, fortran was the 13th paper 
on software presented at these national computer 
conferences. Those papers on software taught me a 
lot, in contrast to some of papers I have listened to at 
this conference. As a matter of fact, there are so many 


\ZH50-’3 AddreSS: R ' W ' Bemer ’ 2 M °° n Mountain Trail. Phoenix, 
■See "Computing Prior to Fortran" in .VCC Proceedings 1982 
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papers on software now that I could not read or §| 
understand them all and still do any useful work. ■.$ 
Computer science education is big now; they give 
doctorates in it. We didn’t have any education of that S 
type. We were apprentices. Early programming is 
where the story originated that if you looked in one 7, 
ear and couldn’t see daylight you could hire the person. 'T; 
In an attempt to try to make some measure, IBM had 
what they called a Programmer’s Aptitude Test. The . J| 
man we are honoring most here today, John Backus, 3 
took it along with the rest of us in Programming 
Research; his score wasn’t the highest! 

Many of us had our own pet questions for selecting JP 
people. I know I did. Other people must have, too, §»| 
because it seemed we were just taking personnel in off 
the streets. David Sayre’s background was in 
crystallography; I was an ex-set-designer for the 
movies. I once decided to advertise for chess players "Ti'7 
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because I thought they would be pretty good 
programmers; it worked very well. We even hired the 
I'.S. chess champion, Arthur Bisguier. He mostly 
played chess and didn’t do that much programming. I 
told that story on a train out to Chicago once, and 
somebody at the next table said, “I’ll send my nephew 
[ n _he is traveling around Europe with a guitar.” The 
nephew came in and announced himself as the chess 
champion of the French Riviera. I didn’t know 
anything about that particular title, so I said, “I can’t 
disprove it, but would you mind playing a game with 
a fellow in here?" He said, “Oh, no, I wouldn’t mind.” 
I went to Bisguier and said, “Hey, Art, we’ve got some 
guy out here who is the chess champion of the French 
Riviera. Would you play a game with him, even though 
it’s not professional?” He said “Yes” and came 
through the door. The guy’s jaw dropped and he said, 
"You can’t fool me — that’s Bisguier!” By the way, the 
champion of the French Riviera was Sid Noble. He 
turned out to be an excellent programmer. 

There wasn’t much formal education, but there was 
a lot of information dissemination in summer sessions 
at MIT, Michigan, and the like. They deserve a great 
deal of credit for that training. Even though we have 
formal training now, I’m afraid we have more 
specialists than generalists. In those days, we were all 
generalists. I think that may have been a pretty good 
situation. 

The concept of stored programming brings thoughts 
to my mind different from the classic ones. I first 
started to program on the IBM 601 cross-footing 
multiplier. I could not understand the IBM manual 
(which I read for a day and a half), so I finally got on 
the machine. A little card traveled along; you cut 
notches in a phenolic strip, which triggered the thing 
off and the card flopped over. Of course, this was a 


program.” We "stored” them on the end of the 
machine on a little paper clip. The 601 looked like 
Gutenberg's oid wrought-iron printing press. Before 
that I knew how to take square root on a Friden 
calculator, and zhat program was “stored” in my head. 

Programming for the 604, the CPC, and such was 
done with plugboards. To use a plugboard, you had a 
bunch of wires of different lengths — they were color- 
coded so you knew their lengths. This is where I first 
ecame interested in programming standards. In the 
CPC days we often had to run the computer around 
e clock. W e needed cola to keep us awake, but cola 
! sn t very good without rum. We kept the rum in the 
on S gTeen wires (my first standard!). Of course, the 
CPC rea hy did have some stored programming in the 
cards, and we had a lot of fun with that. I have a 
Program for the 650 done prior to FORTRAN. Across it 
®d written (as this man’s manager) “clearly no 


knowledge of stored programming.” It was a program 
by Fletcher Jones. 

We had a different type of structure for 
programming in those days; it depended on a drum. 
The drum was still around in the IBM 650. The good 
thing was to pick up the next value needed or the next 
instruction, just as it came by the read head on the 
drum. That is why Stan Poley got into optimizing 
routines. His program was called “SOAP” (Symbolic 
Optimizing Assembly Program). When I went to 
Poley’s apartment in New York one night, I was 
surprised to find that his wife had embroidered 
“SOAP” on one cushion out on the veranda and “650” 
on another one. I thought that was sort of 
ostentatious, except my Arizona license plate now says 
ASCII! That is about the only structured programming 
we really got into before fortran made any 
difference. I think structured programming is still a 
much-needed thing, but I don’t think it is the 
hierarchical structure alone that we need. 

I never heard the term programming portability until 
about 1968. We did do it, of course. The first way was 
to recode the problem, and I recommend that very 
highly. It was originally suggested by Herbert R. J. 
Grosch. The best example of portability I have ever 
seen was the writing of a time-sharing system for a 
Dartmouth GE 600 based on a time-sharing system 
on the GE 235. The documentation was so good that 
they wrote it for a different machine purely on the 
basis of the documentation. It worked better than any 
other portability I’ve seen! The second way was to 
write an interpretative emulator. We wrote lots of 
them in those days, except (unfortunately) they ran 
anywhere between 100 and 1000 times slower. You 
just couldn’t stomach that sort of thing! It lost a 
certain amount of favor, I guess. The third way was 
to use the source language of the interpreter and write 
another interpreter for that language. 

Of course, the fourth way is what we now think of 
as program portability. You take the language and 
build a different processor. As far as I know, the first 
time that was done, at least in any large user 
community, was in FORTRANSIT. This, you may recall, 
was some years before the celebrated running of 
COBOL on two different machines. Unfortunately this 
portability in standards is a lost lesson. A floppy-disk- 
to-fioppy-disk-format machine now exists, with 168 
different formats that can be converted from any one 
to any other! 

Performance measurement is also big today. We 
didn’t have any hardware then to instrument 
performance. We took a lot more care in our original 
coding, particularly because we wanted everything to 
run the very fastest. I got bawled out one morning for 
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not shaving before I came to work. I had to protest 
that I would have, had I come to work, but I was still 
there from the previous day, running a problem on the 
CPC! I’m sure that happened to many people. That is 
why SOAP and other optimizers were so heavily used. 
When the 701 came along, the ratio of programming 
time to running time changed so drastically that some 
of the performance-evaluation necessity went out the 
window. I remember a fellow at Rand who coded a 
problem; it took him two years. When it ran in two 
minutes, he had the doggonedest case of culture shock 
you’ve ever seen. 

We usually published timing with our subroutines 
in those days, so people would know just exactly what 
to use and what they would get. It reminds me very 
much of the jewel work that goes on in micro- 
computers today — particularly to get games inside a 
certain amount of kilobytes in a chip. I suspect that 
FORTRAN had a lot to do with the temporary hi- 
bernation of performance evaluation. You could do so 
much compared to what you could do before that you 
threw performance evaluation out the window and 
squandered it. It wasn’t until we got into operating 
systems and other aspects that we found that we really 
had to measure performance. If we had three machines 
and could get along with one, that would surely be 
nice for our management. 

We did not have time-sharing before FORTRAN, even 
though George R. Stibitz hooked up a relay computer 
to a teletypewriter in 1940. In fact, the first time I 
ever heard (or that I can find) the word timesharing 
was at the same Western Joint Computer Conference 
where the fortran presentation was made, in the 
presentation on the Lincoln TX2 computer. I wrote an 
article that appeared the next month suggesting time- 
sharing. Someone suggested that IBM fire me because 
time-sharing wasn’t their policy, but I think they have 
gotten into it somewhat now. 

Compilers as a class existed before FORTRAN. It is 
my belief that Grace Murray Hopper and the A-0 and 
A-2 people could have gotten a lot farther much faster 
with their early start had they been given the type of 
support that IBM gave to FORTRAN. That was a 
sheltered group! Charles DeCarlo, John McPherson, 
and Cuthbert Hurd all protected those guys. I don’t 
know how they did it in light of the way today’s 
management operates, but they protected and 
believed. The only place where we made a mistake in 
those days was believing that when FORTRAN came 
along we wouldn’t make any mistakes in coding. When 
Backus and his group went on to higher things and 
Dave Hemmes and I were stuck with maintaining 
FORTRAN and getting it out to the field, I made a 
survey. It turned out that on the average, FORTRAN 


programs were compiled (at that time) 50 diffei 
times before they were correct (and each time 
optimization was on). That was very good 

IBM made a lot of money from it. j. 

The concept of data independence arose - 
commercial compiler languages — B-o, Flo' 
COMtran, and COBOL. The data structure of fo: 
was usually built pretty much into the proi 
didn’t have to worry about it. 

We had software piece parts in those days, 
first came to real attention at the Sol 
Engineering Conference in 1968* Bob Glass mafei 
convincing case that SHARE had software 
parts — some of the nicest ones in the world, 
you knew what they did, you could reuse them^ 
you could connect to them. SHARE was 
instrumental in making that concept happen. . s 
We had software packages, but they wei 
packages because we didn’t sell them; noboby 
packages in those days. We weren’t smart enoi 
make money on it; the climate wasn’t there, nol 
thought software was all that important anyway,, 
that was just the way it was. We did take professii 
pride in getting software that people could use., 
IBM Technical Newsletter No. 10 (October 1955). 
done by computer — text processing in 1955! Vi 

Douglas Aircraft had a matrix “abstraction' 
program that would solve matrix equations,, 
multiplication, inversion, and whatnot. Tofi 
anything done on an airplane, you put your probli 
into the matrix form and ran it through the mi 
abstraction. It wasn’t the best method, but it was! 
way you had to do it in those days. There was alstfjj 
lot of interchange for codes for nuclear computal 
We published several of them in Communicatioi 
the ACM, but they were not sold. 

In computing prior to FORTRAN, there was a de: 
split at that time — no question about it. I likedL 1 
days before (and this is an old man’s nosl 
because I think we took a lot more care. I am a ini 
day Miniver Cheevy. Remember? He likedr 
“medieval grace of iron clothing!” Well, there wi 
lot that was medieval about programming prior ij 
FORTRAN, but it was fun. We never did see the Peh 
Principle. We all worked hard, and we were all frii 
The number of levels of management was low; 
control was tenuous, and people trusted you. 
we have better tools and theories, better knowli 
program correctness, and all that sort of stuff, 
don’t think we have any more fun. 


Report a 


* P. Naur and B. Randell (eds.). Software Engineering. 
conference sponsored by NATO Science Committee, Gi 
Germany, October 7-11, 1968. . . 
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Register Allocation in FORTRAN I 
, RICHARD GOLDBERG 

David Sayre and I became intimately acquainted with 
Phase 5 of the FORTRAN I compiler, the section that 
handled register allocation, in the late summer and 
early fall of 1956. Sheldon Best, the designer and 
implementer of Phase 5, was on loan from the Digital 
Computer Laboratory at MIT but returned to Cam- 
p bridge that summer, leaving a debugging gap in the 
compiler group that we undertook to fill. 

When Sayre and I took over, the initial implemen- 
tation of Phase 5 and the four sections of the compiler 
v that preceded it was essentially complete. The project 
was entering a period of intensive interphase debug- 
ging made possible by the fact that realistic input, 
beginning with the FORTRAN source program itself, 
was available for all phases. In this setting, Sayre and 
I became the official exterminators for Phase 5. 

' We were familiar with the general design of the 
phase— the group was closely knit and everything was 
in the air. I do not recall any extensive discussion of 
the implementation with Best before he left; at that 
time most of such a discussion would have been lost 
on us, anyway. We had, or had easy access to, complete 
information about the input to the phase; I had pro- 
grammed Phase 3 whose principal output was an 
intermediate-language version of the source program. 
H Lois Mitchell Haibt, the proprietor of Phase 4, was on 
hand to tell us about the other input — a graph con- 
structed in Phase 4 that defined the “basic blocks” of 
the intermediate- language program and described 
their predecessor-successor relationship. Finally, we 
had a collection of manila folders, our legacy from 
I . Best (in addition to the code itself) that contained his 
documentation of Phase 5 and its various parts — 
comments, flowcharts, table formats, etc. 

With this equipment, Sayre and I descended into 
. Phase 5. To accommodate the irregular working hours 
of the group, some hotel rooms in the vicinity of our 
V = office (and the machine on which the debugging was 
done) were rented. We closeted ourselves in one of 
these rooms and began to explore the contents of the 
S- manila folders and the code listings. Our method 
consisted of redocumenting the phase, bit by bit, as 
we went along. We developed our own table descrip- 
tions and constructed flowcharts that grew, scotch- 
tapewise, as each new piece of the terrain was brought 
• . under control. 
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After a while we started to use the machine. Grad- 
ually, aided by storage dumps, we reached the point 
of understanding the relationship of input to table 
entries — and table entries to new code generated by 
the phase. A little later we knew enough to be able to 
localize and identify bugs — and finally, flushed with 
success, to fix them. In the course of acquiring this 
expertise, it became clear to us that Best had brought 
off a remarkable piece of work, which I will now briefly 
outline. 

By the end of Phase 3, the FORTRAN I compiler 
produced a translation of the source program that, 
except for the symbolic form of its indexes, was ready 
for final assembly to machine code. Phase 4 of the 
compiler then produced, by means of an analysis of 
the control flow of this version of the program and a 
Monte Carlo simulation, a graph whose nodes were 
the “basic blocks” of the program— instruction se- 
quences with single entry and exit points — and whose 
edges, representing the predecessor-successor rela- 
tionship on these blocks, were labeled with estimates 
of the absolute execution frequency of transition. 
From these ingredients. Phase 5 was to devise an 
allocation of the three actual registers of the machine 
to symbolic indexes that would minimize the time 
spent in the resulting program on loads and stores of 
the machine registers. 

The method developed by Best to accomplish this 
proceeded by an iteration in which, successively, a 
register allocation was established for each member of 
a sequence of connected regions or paths, selected, in 
turn, from the input program on the basis of frequency 
information and previously formed regions. More spe- 
cifically, each of these paths consisted of basic blocks 
or earlier regions connected by not-yet-included pred- 
ecessor-successor links of highest frequency; the last 
one was the program itself. A path had one of two 
configurations: (1 ) simple looping, in which each path 
element was a block or transparent region — one whose 
register allocation left at least one of the machine 
registers unused— and each had a unique successor; or 
(2) straight-line, in which the first (or last) path ele- 
ment was an opaque region — one whose register allo- 
cation involved all three machine registers— or a 
transparent region or block with no not-yet-included 
predecessor (or successor). The others were blocks or 
transparent regions. 

A register allocation for a region resulted in not 
only the association of a machine register with every 
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occurrence of a symbolic index in the region (with the 
attendant generation of necessary register loads and 
stores), but also entry and exit conditions for each of 
its blocks — the register assignments required on en- 
trance to a block and those in force on exit. Exit 
conditions also indicated the activity of the index 
associated with a register- on exit — that is, whether 
this index had been initialized or modified in the 
region without a corresponding update of the (unique) 
storage cell in which its current value, when not in a 
register, was saved. A final by-product of the allocation 
was a list of the indexes that were initialized in the 
region. 

To establish a register allocation for a straight-line 
path, the path was traversed starting with empty 
registers; their assignments to indexes along the way 
were governed by the contexts in which they occurred. 
On encountering a region, the entrance conditions of 
the block through which the region had been linked 
were (if possible) matched with the current register 
assignment, perhaps by permuting the registers in the 
region allocation. When the region was transparent, 
the try for a match included considering its unused 
registers as candidates for “passing through” indexes 
of the current assignments (by updating the entrance 
and exit conditions of the blocks of the region appro- 
priately). If entrance conditions could not be satisfied, 
a match was forced by inserting in the path link the 
relevant register loads. Such a load was preceded by 
the necessary store if it replaced an active index. The 
(updated) exit conditions of the block through which 
the region had been linked to the next path element 
became the current register assignment. 

When a block was reached in the traversal, its 
indexed instructions were examined in order. On com- 


Compiler Techniques Available in 1954 

ROY NUTT 

When I first heard the title for this talk, I thought it 
was rather silly. After all, there weren’t any compiling 
techniques in 1954. On reflection, that turned out not 
to be quite true. To give a little background, the open 
literature known to the FORTRAN group in 1954 con- 
tained no compiling articles. One related article, by 
John W. Backus, was on the IBM 701 Speedcode 
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ing upon an instruction with an index that was 
currently associated with a register, the index ' 
assigned to an empty register, if available; others 
it was assigned to the register associated with 
“most replaceable index"-— one that, looking ahead 
the path, was initialized before reuse or reused; r 
remotely. If necessary, a load was inserted imm 
ately before the instruction, preceded by a store; 
active index was replaced. At the end, entrance 
exit conditions for the block were set to reflect' 
resulting allocation, and the exit conditions be 
the current path assignments. 

Best invented a beautiful heuristic to deal 
loops. Ideally a register allocation for a loop shout 
such that the assignment current at its end ms 
that required at its start. To help achieve this, a l 
was “unrolled” once, and the allocation procedure.® 
the straight-line case was applied to the resulting p 
The register assignment current on exit from the 
copy was then used as the initial assignment- 
where applicable, as an indication of terminal in 
reuse — in establishing, via the straight-line proc 
an allocation for the loop. 

All in all, it was a solid, innovative job tha 
weathered gracefully. In a somewhat simpler se 
the replacement criterion used for straight-line p 
was subsequently proved to be optimal. As far 
know, until the late 1970s, the compilers that went! 
for global register assignment at all used variants! 
many of the techniques inaugurated in this early w 

Bernard A. Galler: I remember hearing that P 
was so complex that no one would ever dare to c 
any part of it. Is that true? 

Goldberg: Yes. - 5-1 
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system.* In the closed literature, we knew about 
a-2 compiler at Univac, but to my knowledge we, 
no documentation concerning that system. An. 
ential paper from MIT, by Laning and Zieri eftL 
eluded an interesting interpretive program thatj.^. 

'• , ■. 

* J. W. Backus, “The IBM 701 Speedcoding System.” J- AC 
(January 1954), 4-6. 

**J. H. Laning and N. Zierler, “A Program for Translai 
Mathematical Equations for Whirlwind I.” Engineering Me] 
dum E-364, Cambridge, MIT, January 1954. J 
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Figure 1. Sheridan’s notation. 


ployed an algebraic notation and a convenient method 
for printing the results of the computation. That paper 
influenced my thinking very strongly in the months 
preceding the invitation from Backus to join his group. 
I think other members of the FORTRAN group were 
also aware of that particular system. 

Another bit of background is that FORTRAN was 
designed for a machine with 4096 36-bit words, two 
2048-word drums, and four tapes (75 inches per sec- 
ond, 200 bits to the inch with a 3/4-inch record gap). 
If you have a personal computer with a 10-megabyte 
hard disk today, you have a much bigger machine than 
we did. In the following paper, Frances Allen will tell 
you quite a bit more about the structure of the FOR- 
TRAN compiler, but essentially optimizations were 
achieved in fortran by a number of devices. With 
the elimination of common subexpressions and 
expressions, by restriction of the subscripts used, and 
register assignment (which Dick Goldberg has just 
told you something about), it was possible to do an 
, exhaustive analysis of the manipulations necessary in 
v' DO-loops. 

I want to address two landmark techniques used in 
V ^*e Fortran compiler. First, of course, is the parsing 
1 of algebraic expressions. John Backus and Irving Ziller 
7: "“ooncocted a seemingly dubious scheme for insert- 
tog parentheses around some operations, which could 
~en be unscrambled at a later time to parse the 
“gobraic expression. Peter Sheridan, in an impressive 
W®,* Proved that this was a viable scheme, although 
/ *>me people didn’t particularly care for his notation. 

»oi?l S,lendan ' “The Arithmetic Translator-Compiler of the IBM 
HI 1969)9^2l' Ut0mat ' C ^° < ^ ng System.” Comm. ACM 2, 2 (February 
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CLASSICAL MATHEMATICAL STATEMENTS INTO FORMS DIRECTLY . 
AMENABLE TO AUTOMATIC COOING TECHNIQUES. 

Figure 2. Sheridan’s statement. 


Figure 1 is from a document we affectionately called 
the “Tome.” Figure 2 shows page 20 of that document; 
in retrospect, it is an outstanding statement. 

The second important development in the FORTRAN 
system is the flow analysis done by Sections 4 and 5. 
Everybody in the group recognized the concept of the 
basic block. Sheldon Best developed the concept of 
the region, which has been the foundation for most of 
the significant flow-analysis work that followed (in 
particular, work done at IBM by Fran Allen and John 
Cocke and at Computer Sciences Corporation by Karl 
Balke and Christopher Earnest). Many other people 
also contributed to flow analysis in its modem sense. 

A lot of space has been taken up in the literature 
by sorting and searching. Donald Knuth wrote a mag- 
nificent book* about those subjects. Most of the 
searching done on the FORTRAN compiler was linear 
searching of an unordered table. Some, particularly in 
the assembly-pass ordered-table searching, was done 
by binary search and insert. That was a little better 
than the sap compiler, which I learned was too slow. 
The techniques used in FORTRAN resulted in an assem- 
bly that was about 10 times as fast as SAP. In addition 


* D. E. Knuth, The Art of Computer Programming. Vol. 3, Searching 
and Sorting. Reading, Mass., Addison-Wesley, 1975. 
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Figure 3. An IBM sorter. 
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Figure 4. A row-binary card and a chip. 


Figure 5. The improved row-binary card. 


to the theoretical techniques, there were a few other 
aids to compilation. We used punched cards in those 
days, and occasionally we had a disaster. If you 
dropped your deck, you could solve the problem with 
the IBM sorter (Figure 3). 


In conclusion, I believe that no discussion the$i 
days concerning computers is complete unless tl 
relevant chip technology appears. Figure 4 showsij 
row-binary card, along with a chip. Figure 5 show 
what we did with it. 

.tail 


A Technological Review of the Early FORTRAN Compilers* 
FRANCES E. ALLEN 


When I joined the IBM Research Division in July 
1957—25 years ago— FORTRAN had just come out. My 
first assignment at IBM was to teach FORTRAN to the 
scientists and engineers. We wanted to convince them, 
that it was a usable language. At the time the com- 
puting climate was that everything had to be done 
efficiently. The primary issue in writing a program 
was the efficiency of the program on every single task. 
For example, one of the games played at that time was 
not Pac-Man, but how much function could be put on 
a one-card loader. Getting people away from the no- 
tion that they had to optimize and hand code — very 
carefully hand code — every line they wrote, and con- 
vincing them to use a high-level language, involved 
not only educating them in using that language (which 
was my first assignment), but also convincing them 
that the code produced would be efficient. 

One of the ways the Research Laboratory convinced 
people to use this language was an edict requiring 


Author's Address: F. E. Allen, T. J. Watson Research Center, P.O. 
Box 218, Yorktown Heights, NY 10598. 

* See "A Technological Review of the Fortran i Compiler” in NCC 
Proceedings , 1982, pp. 805-809. 


them to use it! People were soon convinced that it wa? 
an effective way of solving their problems, beca& 
one of the basic goals of the original FORTRAN compiia 
project was to produce code very close to hand code|| 
in fact, as good as hand code in many instances. iyJS 

One example produced essentially perfect code fbj 
the 704. The code produced has, in many instances, 
not been equaled since. Figure 1 is an example ofia 
FORTRAN program with a doubly nested loop in whic| 
we are storing an element from array B into an ele; 
ment in array A. What one might expect is thativK 
will first enter the outer loop and then the next loop 
in the code. . . 

Figure 2 shows what was actually produced by!) the 
FORTRAN I compiler: the 704 code compiled for that 
array move. FORTRAN stores arrays in columns,ahu 
the first compiler stored its arrays backward. So A is 
stored as 100 locations with the first A being atiiijS 
highest address in storage; the same is true for.F^jjjf 
course. The code itself starts by loading register T with 
value 1. The next four instructions are the single JoojJ 
produced by the compiler. What is really happening 
here is that a double loop has been compiled into|| 
single loop. B is then loaded into the accumulate® 
(clear and add an element from B) and is stored 
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DIMENSIONA(10,10) 
DIMENSION B(10, 10) 

DO 1 J = 1 ,1 0 
DOI 1 = 1,10 
1 A(I,J) = B(I,J) 


Figure 1. A FORTRAN program storing array B into array A. 


The index register is changed by 1, and a test is made 
in the last instruction on the value of the index register 
to see whether to go back around the loop or not. In 
other words, the two-dimensional array has been 
linearized. I don't believe that this kind of code has 
been produced since, although the Univac 1107/1108 
FORTRAN compiler also linearized arrays, as Roy Nutt 
has noted in private correspondence. 

Although most of this talk is about the early for- 
tran I compiler and how it related to general tech- 
niques, I would like to spend a couple of minutes on 
CSC’s Univac 1107/1108 compiler because it produced 
excellent code and did so rapidly. It had an excellent 
set of trade-offs between the speed of the compiler 
and the quality of code it produced. One of the inter- 
esting things about the system on which it ran was 
that the tapes could be read backward, and the design 
of the compiler was oriented toward being able to take 
advantage of not having to rewind the tapes. The code 
was translated and put on tape; then the next phase 
would read the tape backward, do something with the 
code, read it forward again, and so forth. Thus the 
compiler produced excellent code very rapidly. 

After teaching FORTRAN, I went on to a number of 
other projects including the design of the compiler for 
the Stretch Harvest machine. I knew quite a bit about 
optimization at that time (I had, in fact, first learned 
about optimization before I joined IBM in a course 
pven by Bernard A. Galler at the University of Mich- 
fgan, where we optimized for the 650). We didn’t pay 
®ny attention to optimization, however, when we de- 
signed the compiler for the Stretch Harvest machine. 
The machine was going to be 100 times faster than 
anything that existed at that time, so we didn’t have 
*®7~ we thought. After going through the project and 
"ring somewhat chastened by the results — not only 
skas the compiler slow, but the object code was very 
slow I went back to looking at optimization and 
* tarte d working with John Cocke. I was also working 
or Richard Goldberg at the time, looking at lots and 
Programs to see what compilers were producing 
snd how we might generalize some of the techniques. 


LXD ONE,1 
LOOP CLA B+1 ,1 
STO A+1,1 
TXI • +1,1,1 

TXL LOOP, 1,1 00 

ONE „1 

A BES 100 

B BES 100 


load 1 into reg 1 


add 1 to regl and go to 
next inst 

if regl si 00 go to loop 

data value one 
reserve 100 Iocs, ending 
with A 

reserve 100 Iocs, ending 
with B 


Figure 2. 704 code compiled for the array move (see Figure 

1 ). 


In the process of doing so we came across the example 
shown in Figure 2 in a slightly more complicated form. 
Cocke looked at it and decided FORTRAN had a bug! It 
took us a while to realize what had been achieved by 
the compiler. 

How was this done? Figure 3 shows the structure of 
the compiler. Section 1 did the translation, and Sec- 
tion 2 did the subscript and DO-statement analysis. 


FORTRAN 


Section 

1 



704 Code 


Figure 3. The compiler structure. 
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There was an interfacer (a “glue” module) between 
Sections 2 and 4. Sections 4 and 5 did the register 
allocation, and Section 6 did the final assembly. This 
organization evolved, as do many complex compiler 
designs, as the problems associated with assigning 
index registers became clearer. The original intent 
was to have just a translator (Section 1); then Section 
2 would do index register allocation, and Section 3 
would be the final assembly. It became clear, however, 
that assigning the index registers had to be done 
correctly. The 704 had three index registers; to get a 
code that was as good as hand code, the assignment 
had to be done well. 

That was harder, it turned out, than producing good 
code for the arithmetic expressions. Housekeeping was 
the hard problem, and it still is the most interesting 
problem in compiler optimization for languages of this 
level. It is the place where compilers can also produce 
the worst code, and unfortunately they do so fre- 
quently. 

With the addition of the interface module, the ac- 
tual design of the compiler evolved a bit from the 
original. One sees such interface modules frequently 
in modern compilers. Sometimes they come about, as 
in this case, as an artifact of the evolving design, but 
sometimes they come about as a result of wanting to 
change data structures between phases (sections). The 
output of a parser, for example, might be a tree. This 
is a nice form in which to do certain kinds of context- 
sensitive analysis, but one may want to switch to 
another form — say, quadruples — in order to make 
global transformations. 

How does the overall organization of this final FOR- 
TRAN I compiler differ from today’s optimizing com- 
pilers? First, today one sees the translation phase, 
Section 1 (the statement identifier and arithmetic- 
statement translator), broken down into several sub- 
parts including syntactic analysis and semantic anal- 
ysis. (Syntactic analysis itself is broken up into lexical 
analysis and parsing.) A lot of the common partitions 
are the result of evolution. The output of the first 
phase case was very low-level code. This was really 
quite surprising. It was essentially machine-level code 
with symbolic registers. In today’s compilers, the out- 
put of an early phase such as this will frequently be 
on a much higher level, where most of the instructions 
to perform the operations have not been exposed. 
Compiler designers are coming back around to this 
design. Optimizing-compiler designers want to expose 
instructions early in order to make optimizing trans- 
formations on them. 

Another difference is that the fourth phase, control- 
flow analysis, would probably be done earlier. A third 
difference is that at the point in this compiler where 


m 


a, 


the global register allocator started to function, 
tically everything else was done. In today’s comp: 
the global register allocator frequently operates', 
high level of intermediate language and, in fact, e 
up making many of the same transformations asf 
earlier parts of the compiler. In summary, the 
nization of this compiler was simple. Most, o: 
complexities arose from the desire to produce c 
programs competitive with hand code. This impS 
need to gather information and postpone prodi 
code until the analysis necessary to produce effi 
code was performed. 

I would now like to look more closely at the 
of the compiler. First, the translator of Sect! 
Today’s compilers often use elegant, language 
pendent translator systems, but the theory h 
these systems didn’t really start to develop until! 
1960s. Actually, Backus’s work in inventing B 
Normal Form and other work that evolved from 
started around 1960. Only in the 1970s, I believe^ 
such systems become widely used in production Qb 
pilers. In the fortran I system, as Roy Nutt mi 
tioned, the translator first created a sequence of aij 
metic instructions, then transformed this sequen 
instructions to eliminate redundant computatio: 
fact, the term common subexpression elimination 
peared in early documentation. It is a transfer 
that has had a lot of attention since then. Iti 
performed here as part of the arithmetic-state: 
translator. In addition to parsing and producing 
code for the arithmetic expressions, the trans 
identified other statements and transformed com; 
input/output lists into their component l)0-nests- 
treatment by the regular mechanisms of the : 
the compiler. The attempt here and in numerous 0 
parts of the compiler was to seek co mm on m 
nisms, not to create special-case mechanisms. T 
interesting and significant in light of the overall 
plexity of the task and the amount of invention 1 
was required for every part of it. This is, of C 
what has been attempted ever since: common, (sun; 
mechanisms that can be applied to cover many : 
tions. j'iplf 

The function of Section 2 of the compile 
subscript and DO-statement analyzer — was to; 
mize the calculation of subscripts and DO con 
statements. Actually, Section 1 produced, in a 
to the low-level form of the program, a set of 
that were analyzed during Section 2 in order to 
mize the calculation of the references to storages 
There is not much interesting to say about! 
interfacer. Section 4, the flow-analysis sectional 
volved finding basic blocks and doing frequency : 
ysis. The basic task of Sections 4 and 5, after 
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1 and 2 finished, was to assign the symbolic registers 
to the real registers so as to minimize the time spent 
’loading and storing into these registers. The first thing 
Uj!at had to be done in Section 4 was flow analysis to 
determine the pattern and frequency of flow for use 
in Section 5, where the actual assignments were made. 

As Roy mentioned, the term basic block was 
mobably invented as part of this project. I would be 
interested in the history of the term, but I haven’t 
found any earlier reference. The program was parti- 
tioned into basic blocks and a flow graph was built. 
Here, then, is the beginning of today’s elegant and 
fast control-flow algorithms. Basic blocks and prede- 
cessor-successor relationships are input to today’s al- 
gorithms. In fact, finding regions really started on this 
project and has been the subject of numerous investi- 
gations since. 

The other task performed in Section 4 was the 
computation of a probable frequency of execution for 
every predecessor edge. A Monte Carlo execution of 
the program with initial weights assigned to each edge 
was developed. This method is no longer used, al- 
though it remains tantalizing. Today, the program 
topology is used more directly but probably with less 
resultant precision. We depend on identifying loops 
in the program and assume they are the most fre- 
quently executed parts of the program. This compiler 
actually attempted to guess or use the edge frequency 
to determine the frequency of execution of different 
parts of the program. 

Section 5 used the information from the previous 


One is struck by the challenge of the project, the 
number of things that had to be invented, and the fact 
that the total problem had not previously been parti- 
tioned into manageable parts. This group had to in- 
vent the partitioning of the problem 9s well as produce 
almost perfect code and do so with practically no 
history. It is a remarkable piece of work, and one of 
the most interesting results is that it has stood the 
test of time. It is truly the case that 25 years later, we 
are still designing compilers based on the techniques 
that were developed on this project. In certain areas, 
such as translators, we have refined things much 
further, and in the areas of optimization and register 
allocation, we have different, perhaps more elegant 
approaches. During the intervening 25 years, however, 
the basic techniques and the way we looked at the 
problems have stood up. Moreover, the compiler pro- 
duced code that still sets a standard for the whole 
industry. "•< 

As I have said, the FORTRAN compiler established 
the standard for object-code efficiency. Perhaps more 
important, it established the feasibility of using high- 
level languages. When I taught the fortran class in 
1957, there was tremendous resistance to using for- 
tran. That resistance was quickly eroded by the kind 
of code the compiler produced. I would like to conclude 
by quoting from a recent paper by Jean Sammet,* in 
which she says, “FORTRAN has probably had more 
impact on the computer field than any other single 
software development.” I believe that. It established 
the feasibility of using high-level languages. 


section to do the register allocation. This is the work 
that Dick Goldberg described; it was an unusually 
good piece of work — a phenomenal piece of work. The 
displacement algorithm for the straight-line code was 
later proved to be optimal. Until very recently, when 
a fast graph-coloring heuristic was successfully applied 
to the global assignment of registers, most global 
assignments were essentially variants of this ap- 
proach. In fact, I t hink this approach has been rein- 
vented at least three times. I have seen at least two 
publications describing it as a new idea, even though 
it is almost exactly the approach that was used in this 
rompiler. I have always been amazed that such a 
general algorithm was applied to assign just three 
tfSjsters! I have wondered what led to the attempt to 
find such a general algorithm. Was it innocence or the 
eoentific challenge of the work? I suspect the latter, 
was certainly an interesting problem and presented 
0 . challenge. Even though the constraint of hav- 

I? , 0n fy t hree registers was formidable, it didn’t pre- 
these people from attempting to find a general 
: ‘ : _ u^hon. In fact, I think the whole project must have 
II * or *ed that way. 


Galler: There was a statement called a frequency 
statement. We were told that it would do a lot for us 
if we knew the branching frequencies, which you re- 
ferred to as the Monte Carlo method. We soon stopped 
using it when the rumor came around that it was being 
ignored anyway. Could you comment on that? . 

Allen: My understanding was that it had been imple- 
mented backward. The test went the wrong way. 
Herbert Meltzer: Your statement is true, but the story 
doesn’t end there. In doing some optimization for the 
compiler itself — that is, when we took something that 
was crammed into 4K and we had this huge amount 
of 32K available — we discovered that what Fran said 
was true. The inference was not taken at the proper 
time. Two of us discovered this at the same time. 
Backus: It was hard to tell whether it was being well 
used or not. Somebody could guess that a particular 
branch was going to go this way and that way so many 

* J. E. Sammet, “History of IBM’s Technical Contributions to High- 
Level Programming Languages.” IBM J. Res. & Dev. 25 y 5 (Septem- 
ber 1981), 520-534. • n *J#ki . / ■■■■•■ ■ b : 


5 of the History of Computing, Volume 6, Number 1 , January 1 984 


Early Days of FORTRAN 


Early Days of FORTRAN 




: ' v -: : " 

i OS 

| Fortran 


Pioneer Day, 1982. Stand 


Richard Goldberg, Lois Haibt, Roy Nutt. 


i left: John Backus, Sheldon Best, Robert Nelson, Irving Ziller. Seated, from left: 


times and was going to influence the calculation of 
how frequently things were done. Apparently, we got 
it wrong and nobody really found out very much about 
it until someone looked into it closely. 

Meltzer: When the IBM 7094 came out with seven 
index registers, was the general allocation system suc- 
cessfully employed to optimize the use of those seven 
registers, rather than three? 

Allen: Bill Heising can answer that question more 
directly. 

William P. Heising: The choice of using only three 
index registers was based on an analysis of the com- 
plexity of the statement to be compiled, not on the 
availability of three registers.* 


Afterword 

JOHN BACKUS 


I would like to discuss what my friends on the FOR- 
TRAN project really accomplished. Fran Allen’s talk 
has made my task simple, because it brings out a little- 
known fact that the computer community has never 
quite recognized: that 25 years ago, my friends did this 


incredible thing of producing a compiler that did| 
better job of optimizing programs in virtually all it 
spects than any compiler in the next 20 years (lint 
1978). In fact, Fran goes so far as to say — and I thin 
she is someone who really understands these thM 

■ toHsurf 
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tions. Herrick should also be credited with introducing 
the key words GO to! Roy Nutt designed most of the 
input/output language and wrote the part of Section 
1 that translated I/O statements into Do-loops. He 
also wrote Section 6, which assembled the final sym- 
bolic program and completed the treatment of I/O 
statements. Nutt should also be credited with the 
introduction of the FORMAT statement. Bob Nelson 
and Irv Ziller wrote Section 2, which turned out to be 
the largest section of the compiler. It analyzed refer- 
ences to arrays in DO-loops and produced highly op- 
timized code for the rest of the source program. Their 
work had a large impact on the overall level of optim- 
ization that I mentioned earlier. Dick Goldberg wrote 
Section 3, which put together the code compiled by 
Sections 1 and 2 and produced some other information 
needed by later sections. People kept conferring and 
going to the authors of earlier sections and asking 
them to produce a little more— a few extra tables that 


Backus: At that time, I think Bill was implement^ 
a compiler whose purpose was to compile faster. Ti 
704 compiler was not the speediest compiler becaus 
it did a lot of analysis. 


Harlan Herrick 


they turned out to need. Dick also played a large part 
in debugging Section 5. Lois Haibt wrote Section 4, 
which made a statistical analysis of the frequency of 
execution (and apparently with regard to the FRE- 
QUENCY statements, we bungled it a little bit), but 
that was really not the main part of the frequency 
analysis. In analyzing DO-loops it did the right thing, 
because the DO-loops said how many times you were 
going to go around the loop. Here Section 4 also 
prepared a lot of tables for Section 5, if I understand 
correctly. Sheldon Best wrote Section 5, which con- 
verted the program using many index registers into 
one using three. His methods have had a great impact 
on later work in the field and a major effect on the 
level of optimization of the compiler. Finally, David 
Sayre wrote an unusually clear and concise program- 
mer’s manual and helped Dick Goldberg to debug 
Section 5. He also helped to manage the project. That 
is the group of people who produced FORTRAN I. 


* The following is from History of Programming Languages , R. Wexeftj 
(ed.). New York, Academic Press, 1981, pp. 69-70. 

Lee: From Mike Shapiro of NCR: “Your paper tries to dispel the leg(i( 
that three subscripts came from three index registers, and yet a fatf 
fortran had a seven index register machine, and therefore had 
subscripts. What are your current thoughts on how many subscript^ 
needed?” 

Backus: Well, I stick by my original story. The complexity of analysis fij 
Bob Nelson and Irv Ziller had to do to optimally deal with indexing ai 
looping rose exponentially as the number of subscripts went up. And.tl| 
was, indeed, the reason we limited it to three. The fact that some m 
group decided to allow seven subscripts in a seven index register mnrhh^ 
that was out of my control. [Laughter] 


David Sayre 

Bk' - 

ip - 

better than most of us— that most of today’s produc- 
! tion compilers do not optimize as well as the FORTRAN 
I compiler. It is unusual for any technical achievement 
! to remain the best in its field for even 5 years. What 
circuit design or program has not been outperformed 
by a successor within 3 or 4 years? It is an incredible 
achievement that 25 years ago these people designed 
and produced a compiler that has remained the best 
overall optimizer for not 5 years, not 10 years, but 20 
years. 

By the way, when I say that somebody “wrote a 
section of the compiler,” it is important to remember 
that what I really mean is that they invented it — they 
developed all the groundbreaking techniques used in 
it It is a great understatement to say only, “Somebody 
wrote a section." 

Peter Sheridan wrote Section 1, which parsed alge- 
braic expressions, translated them into code, and op- 
timized that code. Harlan Herrick invented the DO- 
statement and wrote the part of Section 1 that put all 
the source information that wasn’t used in algebraic 
expressions into tables that were needed by later sec- 


- Peter Sheridan 
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